Recent Mozilla builds from trunk (at least SeaMonkey and Firefox) on FreeBSD 6-STABLE (which uses gcc 3.4.6) break with the following error: ... [snip] jsgc.c gcc -o jsgc.o -c -DOSTYPE=\"FreeBSD6\" -DOSARCH=FreeBSD -DEXPORT_JS_API -DJS_USE_SAFE_ARENA -I/work/mozilla/js/src -I. -I../../dist/include -I../../dist/include/js -I../../dist/include/nspr -I../../dist/sdk/include -I/work/mozilla/js/src -I/usr/local/include -fPIC -I/usr/local/include -I/usr/local/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -fno-strict-aliasing -pipe -DNDEBUG -DTRIMMED -Os -I/usr/local/include -I/usr/local/include -include ../../mozilla-config.h -DMOZILLA_CLIENT -Wp,-MD,.deps/jsgc.pp /work/mozilla/js/src/jsgc.c /work/mozilla/js/src/jsgc.c:189: warning: type of bit-field `prevUntracedPage' is a GCC extension /work/mozilla/js/src/jsgc.c:199: warning: type of bit-field `arenaIndex' is a GCC extension /work/mozilla/js/src/jsgc.c:204: warning: type of bit-field `firstArena' is a GCC extension /work/mozilla/js/src/jsgc.c: In function `js_TraceContext': /work/mozilla/js/src/jsgc.c:2217: error: invalid operands to binary - gmake[5]: *** [jsgc.o] Error 1 gmake[5]: Leaving directory `/work/build/browser/js/src' gmake[4]: *** [libs_tier_js] Error 2 gmake[4]: Leaving directory `/work/build/browser' gmake[3]: *** [tier_js] Error 2 gmake[3]: Leaving directory `/work/build/browser' gmake[2]: *** [default] Error 2 gmake[2]: Leaving directory `/work/build/browser' gmake[1]: *** [build] Error 2 gmake[1]: Leaving directory `/work/mozilla' gmake: *** [build] Error 2 [/snip] ... Since the line in question has been added along with its surrounding block as a patch in bug #408113, I suspect it to have caused the build bustage.

Is the FreeBSD port configured with !JS_HAVE_LONG_LONG? It looks that way, but there is no good reason I know of not to use native 64-bit integer types. GCC has supported them with emulation for a long while, where hardware is lacking. Separately, GCC3.4 is ancient -- I hope FreeBSD can upgrade. It will help avoid port bustage, even if this turns out to be an independent stale configuration bug. /be

I didn't install via ports. I tried to build from trunk using the following mozconfig: mk_add_options MOZ_CO_PROJECT=all mk_add_options MOZ_BUILD_PROJECTS="browser" mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../build ac_add_app_options ${MOZ_BUILD_APP} --enable-application=${MOZ_BUILD_APP} ac_add_options --enable-optimize=-Os ac_add_options --disable-tests The last time i was able to build successfully was on january 26th. On january 30th it failed for the first time (didn't try in between). As far as I can tell JS_HAVE_LONG_LONG is being set from within mozills/js/src/jsosdep.h . Changing the corresponding line to #undef JS_HAVE_LONG_LONG unfortunately doesn't fix the error. If there's anything I could try out as a workaround I'd be willing to do some testing. The upcoming FreeBSD 7-Release will have gcc 4.2 if I remember correctly, but building trunk on FreeBSD7 breaks badly for me. FreeBSD 6.3 was released from Stable about two weeks ago. And I'm afraid FreeBSD 7 won't be declared Stable until after 7.1 or so.

I think brendan meant port in the sense of "adapted version", not BSD's package manager. Could you stick something like this at the start of JS_Context(...): #ifndef JS_HAVE_LONG_LONG XXX #endif (and be sure to undo your change to jsosdep.h) That should tell you whether it's set or not.

brendan: why aren't we using LL_SUB() there?

Because (as I wrote in comment 1, all supported compilers emulate long long if the target ISA doesn't support it. We are not going back to this ugly 64-bit asm style of coding. /be

jag, I hope you meant js_TraceContext(...) instead of JS_Context(...) . I undid all changes to jsosdep.h and then added the following lines: #ifndef JS_HAVE_LONG_LONG # XXX #endif This resulted in the following message (among others): /work/mozilla/js/src/jsgc.c:2210:3: invalid preprocessing directive #XXX So it seems like in fact JS_HAVE_LONG_LONG is not set. But setting it at the start of js_TraceContext(...) by inserting the following didn't help either: #ifndef JS_HAVE_LONG_LONG # define JS_HAVE_LONG_LONG #endif

Erh yeah, I did mean JS_TraceContext(). So I wonder why it's not set. Per http://lxr.mozilla.org/seamonkey/source/js/src/jsosdep.h#92 (included through jstypes.h) it should be. So either XP_UNIX isn't defined or FREEBSD isn't. I'm going to guess it's the FREEBSD define. You could test both using a similar simple compile test. Setting it at the point you did won't help. Preprocessing that depends on it being defined or not has already happened. For fun you could edit jsosdep.h and right before the final #endif add the #ifndef JS_HAVE_LONG_LONG #define JS_HAVE_LONG_LONG #endif, and then rebuild everything, but it's of course not a long-term solution.

You're right. FREEBSD isn't set. I wonder where it should be set and why it isn't. Is it something that should be fixed in FreeBSD or in the Mozilla code?

If you're just building the standalone library or a standalone JS shell, you can use XCFLAGS to add build flags on the command line: XCFLAGS=-DFREEBSD make -f Makefile.ref Not sure how this happens or why this is missing in the mozilla build, if that is the case.

Well, FREEBSD is defined in _freebsd.cfg, which should get copied to dist/include/nspr/prcpucfg.h. It does that based on whether the target system matches *-freebsd* (see http://lxr.mozilla.org/seamonkey/source/nsprpub/configure.in#1139 ) It's included through prtypes.h (apparently from pratom.h, in turn from jslock.h). Find out which pr/include/md/_*.cfg file ends up getting used.

We're probably not using prcpucfg.h in js/src, perhaps we also need to construct some pieces of jscpucfg.h in this same fashion?

I did a make jsgc.i and it claims prcpucfg.h is included (see the chain I mentioned previously). Now per http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/include/prtypes.h#55 we don't include it if MDCPUCFG is defined, which js/src/Makefile.in defines if HOST_NSPR_MDCPUCFG is defined. It doesn't look like that's set for FreeBSD, so we should just get (ultimately) md/_freebsd.cfg. Marco, you're not overriding either the --host or --target, are you?

No. Apart from the mozconfig options I mentioned in comment #2 I just applied a crucial patch to fix build bustage (see first patch from bug #352822) and exported the following variable: LD_LIBMAP="libc_r.so.6=libpthread.so" (so shlibsign won't crash due to conflicting threading libs). CFLAGS is set to "-Os -pipe" in /etc/make.conf . I didn't override any other settings, and my FreeBSD installation should be fairly standard (FreeBSD 6-Stable with the software required to build Mozilla, but without Gnome or NSPR).

Could you run make jsgc.i in $objdir/js/src and e-mail me the file?

Alright, here we go. prcpucfg.h is included too late through the previously mentioned chain for jsosdep.h (included through jstypes.h higher up in jsgc.c) to have FREEBSD defined. Since it seems to depend on at least the platform define in prcpucfg.h we could copy the following into jsosdep.h (from prtypes.h): #ifdef MDCPUCFG #include MDCPUCFG #else #include "prcpucfg.h" #endif or just include prtypes.h itself. Most places that need something like this seem to simply #include prcpucfg.h, but I'm worried that might be breaking compiling for a different host or target platform. Brendan, any strong feelings about this?

Brendan, if you like this we could start removing !defined(JS_HAVE_LONG_LONG) code.

Comment on attachment 301475 [details] [diff] [review] Simplify JS_HAVE_LONG_LONG define based on comment 5 I'm all in favor of defining JS_HAVE_LONG_LONG, if not unifdef'ing and cvs removing jslong.h, etc. But I doubt SunOS4 works any longer (does anyone have a box running it?) and you changed that to turn on long long support that was missing historically. Better to leave alone or (my pref) remove SUNOS4 ifdefs everywhere! /be

Comment on attachment 301475 [details] [diff] [review] Simplify JS_HAVE_LONG_LONG define based on comment 5 Jag, can you minimize or else take on the SUNOS 4 removal? /be

Sure. What about UNIXWARE and _SCO_DS?

There's a long list of dead Unixes there, eh? Yeah, the ones that #undef long long support should die. Leave the rest for another bug. /be

See http://www.caldera.com/skunkware/sgmldocs/scoworld-two/t1.html#AEN114 for why I also removed the __USCL__ bit.

Comment on attachment 304169 [details] [diff] [review] Just get rid of jsosdep.h, #define JS_HAVE_LONG_LONG in jscpucfg.h and generate it from jscpucfg.c, clean up cruft Yay, thanks for cleaning up this old stuff. /be

Checking in src/Makefile.in; /cvsroot/mozilla/js/src/Makefile.in,v <-- Makefile.in new revision: 3.118; previous revision: 3.117 done Checking in src/Makefile.ref; /cvsroot/mozilla/js/src/Makefile.ref,v <-- Makefile.ref new revision: 3.50; previous revision: 3.49 done Checking in src/README.html; /cvsroot/mozilla/js/src/README.html,v <-- README.html new revision: 3.12; previous revision: 3.11 done Checking in src/js.mak; /cvsroot/mozilla/js/src/js.mak,v <-- js.mak new revision: 3.13; previous revision: 3.12 done Checking in src/jscpucfg.c; /cvsroot/mozilla/js/src/jscpucfg.c,v <-- jscpucfg.c new revision: 3.27; previous revision: 3.26 done Checking in src/jscpucfg.h; /cvsroot/mozilla/js/src/jscpucfg.h,v <-- jscpucfg.h new revision: 3.23; previous revision: 3.22 done Checking in src/jslibmath.h; /cvsroot/mozilla/js/src/jslibmath.h,v <-- jslibmath.h new revision: 3.23; previous revision: 3.22 done Checking in src/jslock.c; /cvsroot/mozilla/js/src/jslock.c,v <-- jslock.c new revision: 3.80; previous revision: 3.79 done Checking in src/jslock.h; /cvsroot/mozilla/js/src/jslock.h,v <-- jslock.h new revision: 3.40; previous revision: 3.39 done Removing src/jsosdep.h; /cvsroot/mozilla/js/src/jsosdep.h,v <-- jsosdep.h new revision: delete; previous revision: 3.21 done Checking in src/jstypes.h; /cvsroot/mozilla/js/src/jstypes.h,v <-- jstypes.h new revision: 3.47; previous revision: 3.46 done Checking in src/prmjtime.c; /cvsroot/mozilla/js/src/prmjtime.c,v <-- prmjtime.c new revision: 3.66; previous revision: 3.65 done