471059 - JS does not compile for 64-bit Mac OS X

Status: RESOLVED DUPLICATE of bug 470071

(Core :: JavaScript Engine, defect)

Description

[Nomis101]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; de-de) AppleWebKit/528.8+ (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
Build Identifier: 

I've now installed libidl and its dependencies as universal binarie (i386, x86_64) via MacPorts to compile the mozilla code in 64bit. This solves Bug 469545 for me, but gives me a new problem. Now the build process (x86_64) stops with the error:

/mozilla/xpcom/components/nsIClassInfo.idl:129: Error: unsigned const declaration 'RESERVED' initialized with negative constant

But the really bad thing is, it now stops with the same error if I try to compile the code in i386. So my workaround at the moment is, to deinstall the universal version of glib2 and libidl and reinstall it as i386-only. So I'am at least able to build a i386-version.

To change the gcc-version doesn't help.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Mac OS X 10.5.6, Xcode 3.1.2

Comment 1

[Benjamin Smedberg]

You shouldn't need the x86_64 version of macports. You should be cross-compiling to 64-bit using 32-bit libidl/glib.

That said, the error message doesn't make much sense unless constants overflow oddly.

Comment 2

[Nomis101]

Thanks. Cross-compiling (like in the example in Bug 468509) was my first try. But this gives me another error and so I thought it would be a better way to try it without cross-compiling and x86_64 libs instead. 
And my MacPorts 1.7.0 is the normal version, I only installed libidl, glib2, libiconv, pkgconfig (...) in i386 and x86_64.

Comment 3

[Nomis101]

If I try to build a 64-bit Thunderbird with CROSS_COMPILE=1 on my Intel-Mac, than I get at the moment:


g++-4.2 -arch x86_64 -o jsarray.o -c -fvisibility=hidden -DAVMPLUS_UNIX -DOSTYPE=\"Darwin\" -DOSARCH=Darwin -DEXPORT_JS_API  -DJS_USE_SAFE_ARENA  -I/temp/src/mozilla/js/src -I.  -I./dist/include   -I./dist/include/js -I/temp/src/obj-i386-apple-darwin9.6.0/mozilla/dist/include/nspr -I/sdk/include -I/temp/src/mozilla/js/src    -fPIC  -I/usr/X11/include -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -isysroot /Developer/SDKs/MacOSX10.5.sdk -fno-strict-aliasing -fpascal-strings -fno-common -fshort-wchar -pthread  -DNDEBUG -DTRIMMED -O2  -I/usr/X11/include -DMOZILLA_CLIENT -include ./mozilla-config.h -Wp,-MD,.deps/jsarray.pp /temp/src/mozilla/js/src/jsarray.cpp
In file included from /temp/src/mozilla/js/src/jsarena.cpp:49:
/temp/src/mozilla/js/src/jsbit.h:210: error: size of array ‘arg’ is negative
make[5]: *** [jsarena.o] Error 1
make[5]: *** Waiting for unfinished jobs....
In file included from /temp/src/mozilla/js/src/jsarray.cpp:85:
/temp/src/mozilla/js/src/jsatom.h:69: error: size of array ‘arg’ is negative
In file included from /temp/src/mozilla/js/src/jsarray.cpp:86:
/temp/src/mozilla/js/src/jsbit.h:210: error: size of array ‘arg’ is negative
In file included from /temp/src/mozilla/js/src/js.cpp:56:
/temp/src/mozilla/js/src/jsatom.h:69: error: size of array ‘arg’ is negative
In file included from /temp/src/mozilla/js/src/jsgc.h:48,
                 from /temp/src/mozilla/js/src/jscntxt.h:52,
                 from /temp/src/mozilla/js/src/js.cpp:58:
/temp/src/mozilla/js/src/jsbit.h:210: error: size of array ‘arg’ is negative
In file included from /temp/src/mozilla/js/src/jsapi.cpp:57:
/temp/src/mozilla/js/src/jsatom.h:69: error: size of array ‘arg’ is negative
In file included from /temp/src/mozilla/js/src/jsgc.h:48,
                 from /temp/src/mozilla/js/src/jscntxt.h:52,
                 from /temp/src/mozilla/js/src/jsapi.cpp:60:
/temp/src/mozilla/js/src/jsbit.h:210: error: size of array ‘arg’ is negative
make[5]: *** [js.o] Error 1
/temp/src/mozilla/js/src/jsarray.cpp: In function ‘JSBool array_sort(JSContext*, uintN, jsval*)’:
/temp/src/mozilla/js/src/jsarray.cpp:1882: warning: comparison is always false due to limited range of data type
/temp/src/mozilla/js/src/jsarray.cpp:1986: warning: comparison is always false due to limited range of data type
make[5]: *** [jsapi.o] Error 1
make[5]: *** [jsarray.o] Error 1
make[4]: *** [default] Error 2
make[3]: *** [tier_js] Error 2
make[2]: *** [default] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2

Comment 4

[Josh Aas]

Attachment: current error output

To summarize here, JS does not compile under 64-bit Mac OS X using the mozconfig on bug 468509. The current errors are in this text file, there may be more.

Comment 5

[(not currently active) Ted Mielczarek]

It built fine for me after I fixed bug 468515, so something must have changed.

Comment 6

[(not currently active) Ted Mielczarek]

I can confirm that it's broken in this way if I configure manually like:
CC="gcc -arch x86_64" CXX="g++ -arch x86_64" ../mozilla-central/js/src/configure --target=x86_64-apple-darwin
and then make.

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #1)
> That said, the error message doesn't make much sense unless constants overflow
> oddly.

These errors are the result of JS_STATIC_ASSERT failing. For example, from comment 3, we have:
  /temp/src/mozilla/js/src/jsatom.h:69: error: size of array ‘arg’ is negative
To debug, I look at jsatom.h:69 and see:
  JS_STATIC_ASSERT(sizeof(JSAtom *) == JS_BYTES_PER_WORD);

So from this, I know that JS_BYTES_PER_WORD is incorrect (and continue to debug from there).

Comment 8

[Josh Aas]

JS_BYTES_PER_WORD is incorrectly being defined as "4L" in jsautocfg.h - it should be "8L". The utility "jscpucfg" ("jscpucfg.cpp") is writing out the bad "4L" value, which it gets this way:

sizeof_word         = PR_BYTES_PER_WORD;

The problem appears to be that "PR_BYTES_PER_WORD" is defined as "4L" in a 64-bit Mac OS X configuration.

Comment 9

[Benjamin Smedberg]

This is a generic problem with JS cross-compilation and jscpucfg, and this bug is basically a dup of bug 470071 and perhaps both are a dup of bug 269538.

I *think* that some or all of this may be solved by bug 465460, which purports to use standard autoconfology, but I haven't actually read that patch yet to see if it does away with jscpucfg.

Comment 10

[Benjamin Smedberg]

oops, I meant bug 465640

Comment 11

[Jim Blandy :jimb]

(In reply to comment #9)
> I *think* that some or all of this may be solved by bug 465460, which purports
> to use standard autoconfology, but I haven't actually read that patch yet to
> see if it does away with jscpucfg.

It does not.

Comment 12

[(not currently active) Ted Mielczarek]

Can always dupe forward if you think that other bug is the root cause.