Closed Bug 41524 Opened 24 years ago Closed 24 years ago

Can not build on NetBSD-current

Categories

(SeaMonkey :: Build Config, defect, P3)

x86
NetBSD
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: taya, Assigned: cls)

Details

Attachments

(9 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; NetBSD 1.4Y i386; en-US; m16) Gecko/20000605
BuildID:    2000060510

Current Mozilla could not be built on NetBSD current.
For NetBSD-1.4.2(latest release), built succeeded but not work.


Reproducible: Always
Steps to Reproduce:
1.gmake -f client.mk


Actual Results:  Build failed.
(I forgot detail. But I have a patch to fix this)


Expected Results:  Build succeed.




I made a patch to build mozilla on NetBSD-current.
I considered about NetBSD-1.4.2, so built succeed on 1.4.2 but not worked.It's a
same results without this patch.
I paied the closest attention not to interfere other platform.
I tested the source codes with this patch on Redhat Linux 6.2 and I could
successfully build and run!
Please include this patch to your source tree.
Attached patch patch for NetBSDSplinter Review
taya, can you attach the log of the build errors that you recieve before making
the patch?  I'd like to at least see what we are fixing.  Thanks.

wtc, can you take at look at the nspr portion of this patch?  Thanks.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Let me correct my patch.
Patch to ./nsprpub/pr/src/md/unix/unix.c is not need.
Mozilla can work without this part of patch.
Attached file log of build error
The linking of libplds4.so.1.0 uses "ld -Bshareable .... -lnspr4" to create the
shared lib.  libmozjs.so.1.0 appears to use just "ld -shared ... -lnspr4" which
fails.

What happens if you change -shared to -Bshareable ?
Same result.
-Bshareable is not discribed in ld(1).
According to source code, -shared and -Bshareable are identical.

/usr/bin/ld -Bshareable -o libmozjs.so.1.0   jsapi.o jsarena.o jsarray.o jsatom.
o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.
o jshash.o jsinterp.o jslock.o jslog2.o jslong.o jsmath.o jsnum.o jsobj.o jsopco
de.o jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o
 jsxdrapi.o prmjtime.o        -lm -L../../dist/bin -lplds4 -lplc4 -lnspr4  -luti
l -lm
/usr/bin/ld: cannot open -lplds4: No such file or directory
gmake[3]: *** [libmozjs.so.1.0] Error 1
gmake[3]: Leaving directory `/export/local/src/mozilla/js/src'
gmake[2]: *** [install] Error 2
gmake[2]: Leaving directory `/export/local/src/mozilla/js'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory `/export/local/src/mozilla'
gmake: *** [build] Error 2
Ok, so the next question is why did it work for NSPR?  Can you run nm on
libplds4.so.1.0 and see if it contains the symbols from nspr (say PR_Poll)?  I'm
now wondering if ld just linked in a static copy of nspr.  Also, make sure that
ld being called by nspr is the same as the /usr/bin/ld being used by mozilla.
# nm  libnspr4.so | fgrep PR_Poll
00031618 T PR_Poll
#

NSPR only use -L$(DIST)/lib, so only static library will be used.
Maybe linux box will be the same.
NSPR installs both libnspr4.a and libnspr4.so.1.0
in $(DIST)/lib.  I think if you specify -L$(DIST)/lib,
you get the shared library by default.

We were able to build NSPR libs such as libplds4.so.1.0,
which depends on the core NSPR lib libnspr4.so.1.0.
We did not need to create the symbolic link libnspr4.so -> libnspr4.so.1.0.
Taya, I mean run nm on libplds4 and see if it contains symbols from libnspr4,
which would mean that it statically linked libnspr4 in.  If it was dynamically
linked in, it should look like this:

cls@x:obj> nm dist/bin/libnspr4.so | grep PR_Poll
0002d1f8 T PR_Poll
cls@x:obj> nm dist/bin/libplds4.so | grep PR_Poll
cls@x:obj> ldd dist/bin/libplds4.so 
        /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40005000)
        libnspr4.so => not found
        libdl.so.2 => /lib/libdl.so.2 (0x4000c000)
        libc.so.6 => /lib/libc.so.6 (0x40010000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
cls@x:obj> 

We've been using NSPR for a while on NetBSD for
our project.  Tom Weinstein  <tomw@geocast.com> is one
of the people dealing with it.  I know we hit
some problems with libraries and link paths but
it seemed pretty minor.   Our work has been
on NetBSD/i386 post the ELF switch, and on an
embedded mips platform.

There were some tweaks needed to fix setjmp/longjmp
on mips.  I think we fed those back, but I haven't
looked to see if they are there.
Taya: are ld and /usr/bin/ld different on your system?
Can you do 'which ld' to find out its full pathname?
Cls, sorry for misunderstanding.
There is libnspr4.a and libnspr4.so.1.0 but not libnspr4.so in
dist/lib.
So libplds4.so.1.0 was linked with libnspr4.a staticaly.
I will fix Makfiles to make symlinks and submit new patch later.

Wtc, which version of NetBSD are you using?1.4.2?
As I mentioned at first, mozilla can be compiled on 1.4.2 (a.out format).
But could not be compiled on NetBSD-current(ELF format)

# which ld
/usr/bin/ld
Taya:

I'm using NetBSD 1.4.1 for ARM.  In which NetBSD
release did the ELF switch occur?

Thanks a lot for your patch.  I have the following
questions regarding your patches for files under
mozilla/nsprpub.

1. mozilla/nsprpub/config/NetBSD.mk: why do you use
   -fpic instead of -fPIC?  Why do we need to define
   the macro PIC?  NSPR does not test for PIC.

   What does the -x linker option mean?

   Is LIBRUNPATH needed?

   NSPR is C code only.  Does it need SHLIB_LDSTARTFILE
   and SHLIB_LDENDFILE?

2. mozilla/nsprpub/pr/include/md/_netbsd.h:
   Do you know in which NetBSD release poll() is first
   available?

3. mozilla/nsprpub/pr/src/linking/prlink.c:
   Does dlopen(0, LD_LAZY) not work?  It is legal to
   pass 0 as the first argument to dlopen(), as documented in
   http://www.opengroup.org/onlinepubs/007908799/xsh/dlopen.html.

4. Have you tried building NSPR with pthreads?
> I'm using NetBSD 1.4.1 for ARM.  In which NetBSD
> release did the ELF switch occur?

Did not occur even in NetBSD-1.4.2(latest release).
ELF is used in NetBSD current (maybe become 1.5?) on some platform.
I don't known which platform supports ELF, but at lease i386.

> 1. mozilla/nsprpub/config/NetBSD.mk: why do you use
>     -fpic instead of -fPIC?  Why do we need to define
>     the macro PIC?  NSPR does not test for PIC.

I'm sorry I don't have much knowlege about those options.
I only follows the rule documented in below.

  http://www.netbsd.org/Documentation/elf.html

And /usr/share/mk/bsd.lib.mk also uses -fpic.

>     What does the -x linker option mean?

-x means "Delete all local symbols."

>    Is LIBRUNPATH needed?

Currently, mozilla generates binaries at temporary area (mozilla/dist/bin).
Release package is only a tarball and user get the tarball and extract to 
anywhere he/she wants. At this case, path of libraries are changed from its 
compile time. So LD_LIBRARY_PATH in 'mozilla' shell script adjust the path 
of libraries. It's not a preferable method for ELF in NetBSD(I think).
I want to change the build procces of mozilla to install libraries correct
place like /usr/pkg/lib and use -R/usr/pkg/lib. Maybe this will not be 
acceptable for other platforms, so I will do that in pkgsrc.
So you can remove LIBRUNPATH.

>    NSPR is C code only.  Does it need SHLIB_LDSTARTFILE
>     and SHLIB_LDENDFILE?

Maybe yes.
Without them, mozilla did not work.

> 2. mozilla/nsprpub/pr/include/md/_netbsd.h:
>    Do you know in which NetBSD release poll() is first
>    available?

I'm sorry I don't know.

> 3. mozilla/nsprpub/pr/src/linking/prlink.c:
>     Does dlopen(0, LD_LAZY) not work?  It is legal to
>    pass 0 as the first argument to dlopen(), as documented in
>     http://www.opengroup.org/onlinepubs/007908799/xsh/dlopen.html.

dlopen() is called durling initization function (function called when 
libraries are loaded). This caused a error on NetBSD-current i386.
Without this call, mozilla worked. so I excluded this part.
I think this is a bug of NetBSD.

> 4. Have you tried building NSPR with pthreads?

Because NetBSD does not have system supported pthread, I tried with
pth package in my early work.
But does not work because of some incompatibility.
Hi taya,

I reviewed the NSPR portion of your patch (attachment
id=10158).  I made some changes and produced my proposed
patch (attachment id=10479).  Below are some comments on
my patch for mozilla/nsprpub.

1. mozilla/nsprpub/config/NetBSD.mk: I still use -fPIC
   instead of -fpic.  -fPIC allows branches to have
   large displacements.  I continue to define DLL_SUFFIX
   as "so.0.1" because this allows me to avoid some
   changes to our makefiles.
2. mozilla/nsprpub/pr/include/md/_netbsd.h: I do not
   define _PR_POLL_AVAILABLE and _PR_USE_POLL.  This
   shouldn't affect a client program, which typically
   doesn't have a lot of file descriptors open and
   hence won't run into the FD_SETSIZE limit of select().
   If you tell me how to determine (without using
   autoconf) whether poll() is available, I can add that
   test to our makefiles or source code so that
   _PR_POLL_AVAILABLE and _PR_USE_POLL are defined if
   poll() is available.
3. mozilla/nsprpub/pr/src/linking/prlink.c: I commented
   out the dlopen(0, RTLD_LAZY) call in _PR_InitLinker()
   for NetBSD/ELF.  You said that this is a bug of NetBSD.
   Is it possible to get a bug number for this bug?  I
   want to document my workaround with the bug number so
   that people know when it is safe to remove the workaround
   in the future.
4. mozilla/nsprpub/pr/src/pthreads/ptio.c: I didn't take
   your change because you said NetBSD doesn't have system
   supported pthreads.

You can build and test NSPR with my patch as follows.
# save my patch as file patch.netbsd.
% cvs co -r NSPRPUB_CLIENT_BRANCH mozilla/nsprpub
% patch < patch.netbsd   # apply the patch.
% cd mozilla/nsprpub
% gmake              # this builds NSPR.
% cd pr/tests
% gmake              # this builds NSPR tests.
% cd NetBSD..._DBG.OBJ  # the tests are in this directory.
% ./cvar -d             # run a test
% ./cvar2               # run another test
% ./cltsrv -d           # run yet another test
% ./socket              # yet another test
% ../runtests.ksh       # this shell script runs all the tests.
I forgot to mention that you may need to set
LD_LIBRARY_PATH to <srcdir>/mozilla/dist/NetBSD..._DBG.OBJ/lib
in order to run the NSPR tests.
Is it possible to give me a guest account on a NetBSD
system for NSPR testing purposes?  Thanks.
Some comments on the comments:

> +    If you tell me how to determine (without using
> +    autoconf) whether poll() is available, I can add that  
> +    test to our makefiles or source code so that
> +    _PR_POLL_AVAILABLE and _PR_USE_POLL are defined if   
> +    poll() is available.

poll() is available for all relevant versions of NetBSD (i.e. 1.4 and newer).
So you can just suppose it's there if target is NetBSD.

> +    for NetBSD/ELF.  You said that this is a bug of NetBSD.
> +    Is it possible to get a bug number for this bug?  I
> +    want to document my workaround with the bug number so
> +    that people know when it is safe to remove the workaround
> +    in the future.

This bug was fixed a few days agin in NetBSD-current (and the
upcoming 1.5 release). As we don't have Mozilla building on 1.4.x anyway,
and we will have at least betas of 1.5 in the not so distant future,
I'd say: remove the workaround right now. Or: make it depend on
OBJ_FORMAT=elf, as it doesn't work for the a.out plattforms (and probably
never will).

Actually there is no bug number, because the fix was in before the PR
being written ;-) Mmmm, online communications...

> + 4. mozilla/nsprpub/pr/src/pthreads/ptio.c: I didn't take
> +    your change because you said NetBSD doesn't have system
> +    supported pthreads.

That's right, but there is a pkg'd working version for some architecture,
and we will experiment with that. So being able to use pthreads on NetBSD,
even if not system-supplied yet, would be great!
Martin, thanks for answering my questions.  Based on your comments,
I will define _PR_POLL_AVAILABLE and _PR_USE_POLL, and remove the
workaround for the dlopen(0, RTLD_LAZY) problem.

I'm still not clear about why SHLIB_LDSTARTFILE and SHLIB_LDENDFILE
are needed when building a shared library.  Are their placement on
the command line important?  That is, does SHLIB_LDSTARTFILE need
to be before all the .o files and SHLIB_LDENDFILE need to be after
all the .o files?
    ld -x -shared -soname libfoo.so.1 $(SHLIB_LDSTARTFILE) a.o b.o c.o 
$(SHLIB_LDENDFILE)

What exactly are their purposes?  Are they only required for C++
shared libraries (to invoke global constructors and destructors)?

Is it possible to build a shared library using cc as the front end
to the linker and let cc take care of pulling in $(SHLIB_LDSTARTFILE)
and $(SHLIB_LDENDFILE)?
> I'm still not clear about why SHLIB_LDSTARTFILE and SHLIB_LDENDFILE
> are needed when building a shared library.

Me too ;-)

> What exactly are their purposes?  Are they only required for C++
> shared libraries (to invoke global constructors and destructors)?

They are supposed to not be visible to toolchain users if the approrpiate
options for creating the shared library are used. What I think they do is indeed
process .ini and .fini labeled section (aka constructors/destructors in C++, but
also possibly used by proper __attribute()'d C functions)

I forwarded some background material to Taya, so he will probably come up with a
real solution. He's better at this stuff than me ;-)

I also made someone contact you to get a test account set up, hope this will
work.
Thanks for the info, Martin.  I now have an
account on Tom Spindler's system and have
been playing with it since yesterday. :-)
I just attached a much simplified patch for
mozilla/nsprpub.  I found that I just need
to define DLL_SUFFIX as "so" as opposed to
"so.1.0" for ELF and then I don't need to
make any other changes.  This solution is
not the recommended way of building shared
libraries on NetBSD ELF, but requires minimal
changes to our existing makefiles.

I also found that when building NSPR shared
libraries (all C code) I do not need to link
in $(SHLIB_LDSTARTFILE) and $(SHLIB_LDENDFILE).
wtc, I agree with your suggestion.
Creating DSO with suffix 'so' and do not make symlink is more simple way.
Other part will be more simpler too.

I checked in the NSPR portion of the patch.

On the NSPRPUB_CLIENT_BRANCH.
/cvsroot/mozilla/nsprpub/config/NetBSD.mk, revisions 1.6.72.1, 1.6.72.2
/cvsroot/mozilla/nsprpub/pr/include/md/_netbsd.h, revision 3.7.20.1
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c, revision 3.34.2.5

On the NSPRPUB_RELEASE_4_0_BRANCH.
/cvsroot/mozilla/nsprpub/config/NetBSD.mk, revisions 1.6.58.1, 1.6.58.2
/cvsroot/mozilla/nsprpub/pr/include/md/_netbsd.h, revision 3.7.6.1
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c, revision 3.32.4.7

On the main trunk.
/cvsroot/mozilla/nsprpub/config/NetBSD.mk, revision 1.10
/cvsroot/mozilla/nsprpub/pr/include/md/_netbsd.h, revision 3.10
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c, revision 3.42
The revised minimum patch (attch 10618) has been checked in.  
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
taya -

I don't have a NetBSD system here to test this on.  Are you able to build now
with cls and wtc's changes that were checked in?
Sorry for late answer.
I've already pulled latest source from cvs, and I could build and work mozilla 
successfully!
Many thanks to cls & wtc!
great!

marking verified.
Status: RESOLVED → VERIFIED
Setting OS field so we can find this.
OS: other → NetBSD
Product: Browser → Seamonkey
Blocks: majorbugs
No longer blocks: majorbugs
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: