Closed
Bug 209202
Opened 21 years ago
Closed 20 years ago
libnspr will not build
Categories
(NSPR :: NSPR, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: joe.pepin, Assigned: wtc)
Details
Attachments
(1 file)
20.34 KB,
text/plain
|
Details |
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Build Identifier: will not build ranlib libnspr4.a grep -v ';-' nspr.def | \ sed -e 's,;+,,' -e 's; DATA ;;' -e 's,;;,,' -e 's,;.*,;,' > nsprmap.sun rm -f libnspr4.so gcc -shared -Wl,-h,libnspr4.so,-z,combreloc,-z,defs -Wl,-f,\$ORIGIN/cpu/ \$ISALIST/libnspr_flt4.so -o libnspr4.so -Wl,-M,./nsprmap.sun ./prvrsion.o io/./prfdcach.o io/./prmwait.o io/./prmapopt.o io/./priometh.o io/./pripv6.o io/./prlayer.o io/./prlog.o io/./prmmap.o io/./prpolevt.o io/./prprf.o io/./prscanf.o io/./prstdio.o threads/./prcmon.o threads/./prrwlock.o threads/./prtpd.o linking/./prlink.o malloc/./prmem.o md/./prosdep.o memory/./prshm.o memory/./prshma.o memory/./prseg.o misc/./pralarm.o misc/./pratom.o misc/./prcountr.o misc/./prdtoa.o misc/./prenv.o misc/./prerr.o misc/./prerror.o misc/./prerrortable.o misc/./prinit.o misc/./prinrval.o misc/./pripc.o misc/./prlog2.o misc/./prlong.o misc/./prnetdb.o misc/./prolock.o misc/./prrng.o misc/./prsystem.o misc/./prthinfo.o misc/./prtpool.o misc/./prtrace.o misc/./prtime.o malloc/./prmalloc.o pthreads/./ptsynch.o pthreads/./ptio.o pthreads/./ptthread.o pthreads/./ptmisc.o memory/./prgcleak.o md/unix/./unix.o md/unix/./unix_errors.o md/unix/./uxproces.o md/unix/./uxrng.o md/unix/./uxshm.o md/unix/./uxwrap.o md/unix/./solaris.o md/unix/./os_SunOS.o - L/home/mozilla/dist/lib -lboehm -lpthread -lthread -lrt -lsocket -lnsl -ldl -lc Undefined first referenced symbol in file GetStackTop pthreads/./ptthread.o GC_print_call_tree /home/mozilla/dist/lib/libboehm.so getTypeName /home/mozilla/dist/lib/libboehm.so main /home/mozilla/dist/lib/libboehm.so ld: fatal: Symbol referencing errors. No output written to libnspr4.so collect2: ld returned 1 exit status make[5]: *** [libnspr4.so] Error 1 make[5]: Leaving directory `/home/mozilla/nsprpub/pr/src' make[4]: *** [export] Error 2 make[4]: Leaving directory `/home/mozilla/nsprpub/pr' make[3]: *** [export] Error 2 make[3]: Leaving directory `/home/mozilla/nsprpub' make[2]: *** [nspr] Error 2 make[2]: Leaving directory `/home/mozilla' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/mozilla' make: *** [build] Error 2 Reproducible: Always Steps to Reproduce: 1.cvs co mozilla/client.mk 2.cd mozilla 3.gmake -f client.mk Actual Results: build failed Expected Results: built happily like it used to ;) It used to build just fine a month or so ago, I haven't changed anything to the best of my knowledge.
Assignee | ||
Comment 1•21 years ago
|
||
Are you building on Sun Solaris? Did you specify the --enable-boehm configure option? I believe the --enable-boehm configure option is only supported on Linux x86.
Comment 2•21 years ago
|
||
Reporter, is this still a problem ?
Comment 3•20 years ago
|
||
Yes, this is still a problem (found this bug while searching before filing the same report). Yes, --enable-boehm is passed - otherwise this doesn't manifest (I mean, honestly...). Munging the several Makefiles including this first occurance to do -lboehm on the LIBS line results in a binary but the binary fails to execute (see attached). As Mozilla and Firefox leak about half a gig of RAM/VM a day under heavy use, garbage collection would be really, really nice. In fact, Mozilla leaks faster than even RealServer which had to be the leakiest "production" code out there. Here's my ./configure: ./configure --prefix=/home/knoppix/ --enable-boehm --with-system-jpeg --with-system-png --with-system-zlib --with-x --disable-mailnews --disable-composer --disable-svg --enable-optimize=-O --disable-xul --with-libIDL-prefix=/home/knoppix --disable-ldap --enable-cpp-rtti --libdir=/home/knoppix/lib/ --includedir=/home/knoppix/include I'm building a stripped Mozilla rather than a Firefox as for some reason Mozilla leaks more slowly than Firefox does. I'm building on Knoppix (Debian Linux) to confirm the same problem as it exists on NetBSD. Hence this problem is not Linux specific. Now please don't ask any more "is the computer plugged in?" questions before accepting this report - the first reporter works at RedHat and is presumable both knowledgeable and busy, and you have confirmation. And the first reporter claimed this configuration used to work on his box so he's unlikely to be running a non-supported platform. For what it's worth, the Boehm garbage collection library's support for Linux is secondary to it's Solaris support and the API is identical so it would be truly odd if this configuration failed with Mozilla.
Comment 4•20 years ago
|
||
SEGV: invoked program's (built with --enable-boehm) debugging output SEGV result of attempt to run a program built with --enable-boehm (after Makefile's were munged to do -lboehm).
Assignee | ||
Comment 5•20 years ago
|
||
The build output in the original description (comment 0) clearly shows the build was done on Solaris SPARC and that --enable-boehm was specified. So you are right, my questions in comment 1 were asking about the obvious. The first undefined symbol, GetStackTop, is defined in mozilla/nsprpub/pr/src/pthreads/ptthread.c as follows: 97 #if defined(GC_LEAK_DETECTOR) && (__GLIBC__ >= 2) && defined(__i386__) ... 118 static void* GetStackTop() 119 { 120 stack_frame* frame; 121 frame = GetStackFrame(); 122 while (frame != NULL) 123 { 124 ptrdiff_t pc = (ptrdiff_t)frame->pc; 125 if ((pc < 0x08000000) || (pc > 0x7fffffff) || (frame->next < frame)) 126 return frame; 127 frame = frame->next; 128 } 129 return NULL; 130 } 131 #endif /* GC_LEAK_DETECTOR && (__GLIBC__ >= 2) && __i386__ */ So it is only defined for Linux x86 (the only platform where __GLIBC__ is >= 2 and __i386__ is defined). The second undefined symbol, GC_print_call_tree, is defined in mozilla/gc/boehm/misc.c as follows: 779 #if defined(MACOS) && defined(POWERPC) ... 819 #if NFRAMES > 2 ... 841 #else ... 847 void GC_print_call_tree(call_tree* tree) 848 { 849 UInt32 file_offset; 850 if (GC_address_to_source((char*)tree->pc, symbol_name, file_name, &file_offset)) { 851 MWUnmangle(symbol_name, unmangled_name, sizeof(unmangled_name)); 852 GC_err_printf3("%s[%s,%ld]", unmangled_name, file_name, file_offset); 853 } else { 854 pc2name((word)tree->pc, symbol_name, sizeof(symbol_name)); 855 MWUnmangle(symbol_name, unmangled_name, sizeof(unmangled_name)); 856 GC_err_printf2("%s(%08X)", unmangled_name, tree->pc); 857 } 858 } ... 879 #endif /* NFRAMES > 2 */ 880 881 #elif defined(LINUX) ... 887 void GC_print_call_tree(call_tree* tree) 888 { 889 Dl_info dlinfo; 890 if (dladdr(tree->pc, &dlinfo) >= 0) { 891 unsigned offset = (tree->pc - dlinfo.dli_fbase); 892 GC_err_printf3("%s[%s +0x%08X]", dlinfo.dli_sname, dlinfo.dli_fname, offset); 893 } else { 894 GC_err_printf2("%s(0x%08X)", "(unknown)", tree->pc); 895 } 896 } ... 919 #else ... 950 #endif /* !MACOS */ So it's only defined on Mac OS (probably Mac OS Classic, not Mac OS X) and Linux. These two findings are sufficient for me to conclude that Mozilla build with --enable-boehm specified is not supported on Solaris SPARC. I don't maintain the boehm code in Mozilla or NSPR, so I'm going to mark this bug WONTFIX. The problem reported in comment 3 is a different problem. - It is a runtime crash on Knoppix (Debian Linux), not a build problem on Solaris SPARC. - The debugging output provided in comment 4 does not contain either GetStackTop or GC_print_call_tree.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
OS: other → Solaris
Hardware: Other → Sun
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•