Closed
Bug 41524
Opened 24 years ago
Closed 24 years ago
Can not build on NetBSD-current
Categories
(SeaMonkey :: Build Config, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: taya, Assigned: cls)
Details
Attachments
(9 files)
12.91 KB,
patch
|
Details | Diff | Splinter Review | |
2.30 KB,
text/plain
|
Details | |
13.12 KB,
patch
|
Details | Diff | Splinter Review | |
5.83 KB,
patch
|
Details | Diff | Splinter Review | |
6.22 KB,
patch
|
Details | Diff | Splinter Review | |
5.49 KB,
patch
|
Details | Diff | Splinter Review | |
2.52 KB,
patch
|
Details | Diff | Splinter Review | |
2.78 KB,
patch
|
Details | Diff | Splinter Review | |
6.54 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•24 years ago
|
||
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
Reporter | ||
Comment 3•24 years ago
|
||
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.
Reporter | ||
Comment 4•24 years ago
|
||
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 ?
Reporter | ||
Comment 6•24 years ago
|
||
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.
Reporter | ||
Comment 8•24 years ago
|
||
# 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.
Comment 9•24 years ago
|
||
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.
Assignee | ||
Comment 10•24 years ago
|
||
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>
Comment 11•24 years ago
|
||
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.
Comment 12•24 years ago
|
||
Taya: are ld and /usr/bin/ld different on your system? Can you do 'which ld' to find out its full pathname?
Reporter | ||
Comment 13•24 years ago
|
||
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
Reporter | ||
Comment 14•24 years ago
|
||
Comment 15•24 years ago
|
||
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?
Reporter | ||
Comment 16•24 years ago
|
||
> 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.
Comment 17•24 years ago
|
||
Comment 18•24 years ago
|
||
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.
Comment 19•24 years ago
|
||
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.
Comment 20•24 years ago
|
||
Is it possible to give me a guest account on a NetBSD system for NSPR testing purposes? Thanks.
Comment 21•24 years ago
|
||
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!
Comment 22•24 years ago
|
||
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)?
Comment 23•24 years ago
|
||
Comment 24•24 years ago
|
||
Comment 25•24 years ago
|
||
> 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.
Comment 26•24 years ago
|
||
Thanks for the info, Martin. I now have an account on Tom Spindler's system and have been playing with it since yesterday. :-)
Comment 27•24 years ago
|
||
Comment 28•24 years ago
|
||
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).
Comment 29•24 years ago
|
||
Reporter | ||
Comment 30•24 years ago
|
||
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.
Reporter | ||
Comment 31•24 years ago
|
||
Comment 32•24 years ago
|
||
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
Assignee | ||
Comment 33•24 years ago
|
||
The revised minimum patch (attch 10618) has been checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 34•24 years ago
|
||
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?
Reporter | ||
Comment 35•24 years ago
|
||
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!
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•