Closed
Bug 43826
Opened 24 years ago
Closed 22 years ago
Nightly Build failure with workshop 6 (AKA forte6) SPARC
Categories
(Core :: Layout, defect, P2)
Tracking
()
RESOLVED
FIXED
People
(Reporter: neel, Assigned: scc)
Details
(Whiteboard: [nsbeta3-])
Attachments
(1 obsolete file)
Workshop6 nigtly builds have been failing for the past 2 days(begining 0623) with the following error ===== "nsStyleContext.cpp", line 2035: Error: "nsStyleContextData::AddRef()" has already been called and cannot be defined inline. ===== Machine : ultra1 (sparc) OS : solaris 2.7 CFLAGS : -O -library=iostream -xarch=v8plus
Reporter | ||
Comment 1•24 years ago
|
||
see also bugs 39730 and 39133
Reporter | ||
Comment 2•24 years ago
|
||
The nightly build has now been failing with the following error =============== nsAlgorithm.h", line 72: Error: Formal argument iter of type char**& in call to static nsCharSinkTraits::write(char**&, char*const*, unsigned) is being passed char*. "nsAlgorithm.h", line 72: Error: Formal argument s of type char*const* in call to static nsCharSinkTraits::write(char**&, char*const*, unsigned) is being passed const char*. 2 Error(s) detected. ================ I am changing the priority of the bug, 'coz we are unable to build mozilla with workshop6 for the past few weeks.
Severity: normal → blocker
Priority: P3 → P2
Summary: Nightly Build failure with workshop 6 (AKA forte6) → Nightly Build failure with workshop 6 (AKA forte6) SPARC
Comment 6•24 years ago
|
||
Neelakanth Nadgir: let me explain you how things work here when a build gets broken. It's fairly simple: 1) We fix it on our local machine. 2) We check the fix in. Alternatively, if you don't have checkin privileges, you can send a patch to the programmer whose checkin broke your build. Opening a bug report is the least efficient method to deal with build breakages. I'm closing as WontFix, a bit puzzled by the episode. Don't ask yourself what Mozilla can do for you, ask yourself what you can do for Mozilla.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Comment 7•24 years ago
|
||
pierre, what the fuck kind of resolution is that? this breaks an entire fucking platform. this keeps me from being able to run quantify and purify which blocks me from fixing my nsbeta3+ bugs. don't resolve build bustage as wontfix. that is utter bullshit.
Comment 8•24 years ago
|
||
reassigning since someone doesn't care about some platforms.
Assignee: pierre → pavlov
Status: REOPENED → NEW
Comment 9•24 years ago
|
||
Comment 10•24 years ago
|
||
I've checked in a fix for the first build problem. I was seeing this with WS5. scott? the other part is in your code.
Comment 11•24 years ago
|
||
I won't take no fuck nor bullshit and I hope the reporter will show a little bit more sense of responsibilities in the future like any other programmer on the project. This bug was reported on 06/26 against a build breakage with an obvious fix. Filing a bug report everytime Tinderbox turns red would be completely counter-productive, that's why we don't do it.
Comment 12•24 years ago
|
||
Although the bonsai-hook mailing list and the build newsgroup are sometimes used to get build-bustage fixes communicated more quickly, bugzilla is a completely appropriate mechanism for reporting bugs that cause compile-time errors. The reporter did exactly the right thing by filing this bug. Pierre, in the future, please reassign legimate bugs such as this one if you are unwilling or unable to fix them.
Comment 13•24 years ago
|
||
Alright, sorry everybody, I stand corrected (but I'm still not taking no fuck nor bullshit or at least not in writing in public forums - send them over the phone: I always enjoy having a chance to express my love :-P ). As a more positive contribution to this bug, I humbly suggest to reassign it to scc to take care of the bustage in nsAlgorithm.h. If it's urgent, you can also send him a patch directly.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 15•24 years ago
|
||
The nsAlgorithm.h portion of this bug looks like a compiler problem at first blush. The compiler has suspiciously gotten the type wrong, adding an extra |*|. But wait, this is a partially specialized template --- note the template <class CharT> struct nsCharSinkTraits<CharT*> could that be where it got the extra |*|? I need to know what auto-conf says the value of |HAVE_CPP_PARTIAL_SPECIALIZATION| is. Did workshop pass the test? If so, perhaps the test isn't strong enough. If not, then I'm barking up the wrong tree. Neelakanth: can you check the value of this auto-conf produced define? If it is _not_ defined, then I need to keep searching. If it _is_ defined, then we have a probable compiler bug. Should I assign the bug back to you until you determine this?
Reporter | ||
Comment 16•24 years ago
|
||
looking at config/autoconf.mk, ACDEFINES has -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 all: I am not a c++ guru, but if i was, i would have definetly helped fixing this bug.
Assignee | ||
Comment 17•24 years ago
|
||
All right, so we may be on the right track. What happens if you _force_ |HAVE_CPP_PARTIAL_SPECIALIZATION| to be undefined? If this then allows you to build, then we know that you have a compiler bug and we need to fix the partial specialization auto-conf test to account for it.
Reporter | ||
Comment 18•24 years ago
|
||
it compiles cleanly if we undefine HAVE_CPP_PARTIAL_SPECIALIZATION . I tried this with M17 and workshop6
Assignee | ||
Comment 19•24 years ago
|
||
Terrific. OK, forte6 has a compiler bug in its support for template partial specialization. To account for this, we need to make the autoconf test case for |HAVE_CPP_PARTIAL_SPECIALIZATION| stronger. In the mean time, a temporary fix to get you building again is force-undefine this symbol in autoconf, as you have demonstrated. Now the problem is, I'll need access to a machine+compiler that exhibits this behavior so that I can fix the test. Do you have a machine I can telnet into? Or, actually, would it be easier for me to post an exploratory patch or two to this bug, that you could apply to the autoconf tests until we can get the test to fail? Perhaps even easier, I'll look for a machine with this configuration internally. I'll ask mcafee and waterson.
Comment 20•24 years ago
|
||
This change also fixes Bug 21138 and Bug 43636 but now I'm getting CC -library=iostream -o nsStdURL.o -c -DOSTYPE=\"SunOS5\" -DOJI -I../../../dist /include -KPIC -mt -O -DNDEBUG -DTRIMMED -DMOZILLA_CLIENT -DBROKEN_QSOR T=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_GTK=1 -DMOZ_DEF AULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAV E_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DH AVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHA VE_SYS_FILIO_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBRESOLV=1 -DHAVE_LIB SOCKET=1 -DHAVE_LIBNSL=1 -DHAVE_LIBELF=1 -DHAVE_LIBINTL=1 -DHAVE_LIBPOSIX4=1 -DH AVE_LIBW=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_QSORT=1 -DHAVE_STRERROR=1 -DHAV E_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS =1 -DHAVE_MEMMOVE=1 -DHAVE_USLEEP=1 -DHAVE_RINT=1 -DHAVE_GETTIMEOFDAY=1 -DGETTIM EOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1 -DHAVE_IOS_BINARY=1 -DHAVE_OSTREAM=1 -DHAVE_ CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE _SYNTAX=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USIN G=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_ NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATI ONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUP PORTED=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_MATHML=1 -DMOZ_DLL_SUFFIX=\".so\" -DX P_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 -DLAYERS=1 nsStdURL.cpp "", line 129: Error: String/char constants may not include line separator. ** Assertion ** : 0 (/set/taz/builds/fcs0406/intel-S2/lang/cafe/resources/cdr/sr c/c_dataparse.cc: 967) gmake[3]: *** [nsStdURL.o] Error 199 gmake[3]: Leaving directory `/home/doehrm/mozilla/netwerk/base/src' gmake[2]: *** [install] Error 2 gmake[2]: Leaving directory `/home/doehrm/mozilla/netwerk/base' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/home/doehrm/mozilla/netwerk' gmake: *** [install] Error 2
Comment 21•24 years ago
|
||
Marcus, that's bug 43626 (your's I believe), and that's a bug in the Sun compiler. That's still going to cause Workshop 6 builds to fail on Solaris Intel.
Comment 22•24 years ago
|
||
I deleted (?) after configuring the -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 from the config/autoconf.mk file. Now I'm getting this: CC -library=iostream -o nsIOService.o -c -DOSTYPE=\"SunOS5\" -DOJI -I../../../d ist/include -KPIC -mt -O -DNDEBUG -DTRIMMED -DMOZILLA_CLIENT -DBROKEN_Q SORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DULTRA_SPARC=1 -DD_INO=d_ino -DMOZ_WID GET_GTK=1 -DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DH AVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -D HAVE_UINT16_T=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DH AVE_UNISTD_H=1 -DHAVE_SYS_FILIO_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIB RESOLV=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBNSL=1 -DHAVE_LIBELF=1 -DHAVE_LIBINTL=1 -DH AVE_LIBPOSIX4=1 -DHAVE_LIBW=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_QSORT=1 -DHA VE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME _R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_USLEEP=1 -DHAVE_RINT=1 -DHAVE_GETT IMEOFDAY=1 -DGETTIMEOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1 -DHAVE_IOS_BINARY=1 -DHAV E_OSTREAM=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_ SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIG UITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOT EQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_ UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_MAIL_NEWS=1 -DMOZ_ENDER _LITE=1 -DNS_MT_SUPPORTED=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_MATHML=1 -DMOZ_DLL _SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 -DLAYERS=1 nsI OService.cpp CC: -D option without arguments SunWS_cache: Error: Error occurred in invoked compiler, exit status = 1(2). Abo rting.... gmake[3]: *** [nsIOService.o] Error 1 gmake[3]: Leaving directory `/export/home/doehrm/mozilla/netwerk/base/src' gmake[2]: *** [install] Error 2 gmake[2]: Leaving directory `/export/home/doehrm/mozilla/netwerk/base' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/export/home/doehrm/mozilla/netwerk' [doehrm@sun8 ~/mozilla]$ what `which CC` | egrep -i workshop RELEASE VERSION Sun WorkShop 6 2000/04/07 C++ 5.1 [doehrm@sun8 ~/mozilla]$ uname -a SunOS sun8 5.8 Generic_108528-02 sun4u sparc SUNW,Ultra-5_10 Was that wrong DELETING this line? Setting it to '0' does not help...
Comment 23•24 years ago
|
||
This -D problem is the one that has blocked me from compiling Mozilla with Sun C++ v5.0 since early June. I have just upgraded to C++ v5.1 and should have a patch from Sun that addresses *that* problem Monday, August 21. I can supply the patch # to the Sun folk involved in this (it's not yet a public patch so I can't give it here).
Assignee | ||
Comment 24•24 years ago
|
||
OK, so there's a work-around in place ... and the remaining blocker is bug 43626; that means I can mark this bug nsbeta3-. We'll still get around to fixing the autoconf test, though.
Whiteboard: [nsbeta3-]
Comment 25•24 years ago
|
||
I'm just curious if there are any news on this compiler 'bug'...
Comment 26•24 years ago
|
||
We are using Gnu compilers for our Solaris Netscape 6 release, and have not dealt with the Sun compiler group for 2-3 months, so I have no idea on the status of this patch. Neel, you've been working with the Sun compilers group to try to build Mozilla. Is there anything that interested developers can do to get a version of the Forte compiler that's capable of building latest Mozilla?
Reporter | ||
Comment 27•24 years ago
|
||
The Sun C++ compiler team assures me that the latest version of Forte Developer (6 Update 1) compiles mozilla cleanly. I havent tried it out. If anybody is interested in trying it out, please send me an email, I will be glad to ship you a CD and a demo license.
Comment 28•24 years ago
|
||
I assume you mean patch 109490-01 and 109491-02? I'll try this this evening.
Comment 29•24 years ago
|
||
I'm getting now a weired error: gmake[2]: Entering directory `/export/home/doehrm/mozilla/xpfe/bootstrap' CC -library=iostream -o mozilla-bin -mt -O -DNDEBUG -DTRIMMED -DWIDGET_DLL=\"li bwidget_gtk.so\" -DGFXWIN_DLL=\"libgfx_gtk.so\" -I/opt/sfw/lib/glib/include -I/o pt/sfw/include nsAppRunner.o nsSetupRegistry.o nsSigHandlers.o -xildoff -L ../../dist/bin -L../../dist/lib -Qoption ld -z,allextract -lxpfelocation_s -lmpf ilelocprovider_s -lgkgfx -L../../dist/bin -lxpcom -lmozjs -ljsj -lplds4 -lplc4 -lnspr4 -lpthread -lw -lposix4 -lintl -lelf -lnsl -lsocket -lresolv -liostream -lCrun -ldl -lm ld: fatal: symbol `__copyright' is multiply defined: (file /opt/SUNWspro/WS6/lib/libiostream.a(release.o) and file /opt/SUNWs pro/WS6/lib/libCstd.a(release.o)); ld: fatal: File processing errors. No output written to mozilla-bin gmake[2]: *** [mozilla-bin] Error 1 gmake[2]: Leaving directory `/export/home/doehrm/mozilla/xpfe/bootstrap' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/export/home/doehrm/mozilla/xpfe' gmake: *** [install] Error 2 It really seems to be compiler specific. Since I don't have access to sunsolve actually (network problem) could someone @Sun please do a quick search?
Reporter | ||
Comment 30•24 years ago
|
||
Are you sure you are not mixing standard iostreams with classic iostreams? i.e are all objects built with -library=iostreams ? Another workaround, though ugly is to convert libiostream.a into libiostream.so. let me know if you have further problems.
Comment 31•24 years ago
|
||
Please apologize, but how to check this? Since I didn't write the output into a logfile, I cannot check. As far as I remember, I always saw CC - library=iostream but I can't prove. Conversion: How do I convert a static library in a shared one (without having the sources)?
Reporter | ||
Comment 32•24 years ago
|
||
OK, here is how i build it. I set CFLAGS="-library=iostreams" and then configure. this always works for me. To convert a .a to a .so, use CC -G -Kpic -o foo.so foo.a
Comment 33•24 years ago
|
||
Ok, getting the following: doehrm@sun8 ~/mozilla]$ CC=cc CXX=CC ./configure --disable-debug --enable-opti mize --enable-mathml --enable-svg --disable-tests loading cache ./config.cache checking host system type... sparc-sun-solaris2.8 checking target system type... sparc-sun-solaris2.8 checking build system type... sparc-sun-solaris2.8 checking for gcc... (cached) cc checking whether the C compiler (cc -library=iostreams ) works... no configure: error: installation or configuration problem: C compiler cannot creat e executables. [doehrm@sun8 ~/mozilla]$ cat config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:769: checking host system type configure:790: checking target system type configure:808: checking build system type configure:1795: checking for gcc configure:1908: checking whether the C compiler (cc -library=iostreams ) works configure:1924: cc -o conftest -library=iostreams conftest.c 1>&5 ld: fatal: library -library=iostreams: not found ld: fatal: File processing errors. No output written to conftest configure: failed program was: #line 1919 "configure" #include "confdefs.h" main(){return(0);} Am I silly? (sorry, must be _very_ basic...)
Comment 34•24 years ago
|
||
Ok, the problem seems to be fixed with Update-1 of Forte 6/5.1. I'm writing this on a mozilla compiled with forte on sparc. :-)
Comment 35•24 years ago
|
||
Current state: I installed a new machine with SunOS 5.8/SPARC/Forte6U1 and MU2 one with SunOS 5.8/INTEL/Forte6U1. The build on Sparc works currently, the build on Intel doesn't. I builds fine with the following configuration: [doehrm@wwwpits ~/mozilla/dist/bin]$ cc -V cc: Sun WorkShop 6 update 1 C 5.2 2000/09/12 [doehrm@wwwpits ~/mozilla/dist/bin]$ grep -i update /etc/release Solaris 8 Maintenance Update 3 applied [doehrm@wwwpits ~/mozilla/dist/bin]$ cat ~/.mozconfig mk_add_options MOZ_CVS_FLAGS=-q ac_add_options --disable-tests ac_add_options --disable-debug I'm doing the build with 'CC=cc CXX=CC gmake -f client.mk' The build runs fine without optimization, however, after starting the app sigsegv: <snip> RegSelf Unicode to IBM857 converter complete RegSelf Unicode to IBM862 converter complete RegSelf Unicode to IBM864 converter complete Segmentierungsfehler - Speicherabbild 'core' geschrieben (dbx) where =>[1] PL_HashTableEnumerateEntries(0x8188580, 0xdf9e4340, 0x0), at 0xdf8614f0 [2] nsHashtable::Reset(0x8188578, 0x0, 0x0), at 0xdf9e4479 [3] nsHashtable::Reset(0x8188578, 0x8045a50, 0x8045e48, 0x8045a4b, 0x0, 0x8158 ec8, 0x8045e20), at 0xdf9e43fe [4] nsXPCWrappedNativeClass::CallWrappedMethod(0x8182ff0, 0x8188578, 0x8184160 , 0x815cf3c, 0x1, 0x0, 0x0, 0x80462d4), at 0xdf4b0dcf [5] WrappedNative_GetProperty(0x8188578, 0x8158ec8, 0x815e0e0, 0x80462d4), at 0xdf4b32bb [6] js_Interpret(0x8188578, 0x804660c), at 0xdf91ff4c [7] js_Execute(0x8188578, 0x8158eb8, 0x81b08c0, 0x0, 0x0, 0x804660c), at 0xdf9 168e9 [8] JS_ExecuteScript(0x8188578, 0x8158eb8, 0x81b08c0, 0x804660c), at 0xdf8e729 a [9] mozJSComponentLoader::GlobalForLocation(0x8163590, 0x8151358, 0x8163620), at 0xdf4492a1 [10] mozJSComponentLoader::ModuleForLocation(0x8163590, 0x8151358, 0x8163620), at 0xdf447e39 [11] mozJSComponentLoader::AttemptRegistration(0x8163590, 0x8163620, 0x0), at 0xdf446f38 [12] mozJSComponentLoader::AutoRegisterComponent(0x8163590, 0x0, 0x8163620, 0x 8046bd8), at 0xdf446b17 [13] mozJSComponentLoader::RegisterComponentsInDir(0x8163590, 0x0, 0x807c628), at 0xdf44620b [14] mozJSComponentLoader::AutoRegisterComponents(0x8163590, 0x0, 0x807c628), at 0xdf445fb2 [15] AutoRegister_enumerate(0x8160350, 0x8163590, 0x8047360), at 0xdfa64b31 [16] _hashEnumerate(0x816a000, 0x1, 0x8046d10), at 0xdf9e3bc7 [17] PL_HashTableEnumerateEntries(0x807a3d8, 0xdf9e3b80, 0x8046d10), at 0xdf86 1500 [18] nsHashtable::Enumerate(0x807a3d0, 0xdfa64ad0, 0x8047360), at 0xdf9e4327 [19] nsComponentManagerImpl::AutoRegisterImpl(0x80774d0, 0x0, 0x0), at 0xdfa65 ecf [20] nsComponentManagerImpl::AutoRegister(0x80774d0, 0x0, 0x0), at 0xdfa64c66 [21] nsComponentManager::AutoRegister(0x0, 0x0), at 0xdfa73246 [22] NS_AutoregisterComponents(), at 0x805bb82 [23] NS_SetupRegistry_1(0x1), at 0x805bcbc [24] main1(0x1, 0x8047a70, 0x0), at 0x8058bcf [25] main(0x1, 0x8047a70, 0x8047a78), at 0x805b06f The non-optimized debug compile does also sigsegv. With optimization enabled (--enable-optimize) the build fails at js/src/jsinterp.c (see Bug 43626). So does anyone have an idea what's happening here?
Updated•22 years ago
|
Attachment #12160 -
Attachment is obsolete: true
Comment 36•22 years ago
|
||
I'm not sure I get it, is this bug just used for dumping general problems on this platform? Is it still a blocker?
Comment 37•22 years ago
|
||
hwaara: this isn't unusual, the reason to recycle a build failure bug for a special os/compiler is because you've already collected a useful CC list. i have solaris8intel here, i suppose i could get the SunONE trial for it and try building (in vmware). -- I'll try to look into that sometime this month.
Reporter | ||
Comment 38•22 years ago
|
||
I havent built the nightly builds recently, but "it should work". The sun compiler team builds mozilla as a part of the their nightly QA. If it doesnt build, plz let me know so that i can pass it along.
Assignee | ||
Comment 39•22 years ago
|
||
there seem to be no recent open concerns. closing this bug accordingly
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•