This bug report addresses two problems: 1) On lib64 architectures like x86-64 (but also ppc64 and sparc64), 64-bit libraries got to */lib64 instead of the regular */lib directories. 2) Implement VARARGS_ASSIGN with the standard va_copy() macro on x86-64.

Hi, I forgot to mention the patch also adds -fPIC required to build DSO on x86-64. However, the way it's done is surely not the cleanest one.

Reassigning to Kenton; cc'ing Brendan, rginda. Note the provided patch has some binary information at the top of the file -

The bottom of the file looks corrupted, too. Could one of the developers advise Gwenole on what might have gone wrong? Thanks -

Sorry, I hope it's OK this time.

line #else /* __alpha */ should read #else /* __alpha || __x86_64__ */

Comment on attachment 95612 [details] [diff] [review] JS fixes for Linux/x86-64 r=shaver. Let's see about getting this in for 1.4b, if there's still time.

Comment on attachment 95612 [details] [diff] [review] JS fixes for Linux/x86-64 a=asa (on behalf of drivers) for checkin to 1.4b.

Comment on attachment 95612 [details] [diff] [review] JS fixes for Linux/x86-64 a=asa (on behalf of drivers) for checkin to 1.4

Comment on attachment 95612 [details] [diff] [review] JS fixes for Linux/x86-64 I checked this in. I'm sorry it missed 1.4b the va_copy change sort of conflicted with a change for bug 187180, please make sure that the way i resolved it works.

timeless: is this ready to be marked FIXED, then?

I'm uncomfortable resolving bugs for things I can't test. I'd rather Gwenole resolve it.

This checkin has broken the build of the JS shell on Windows. I get an error on WinNT4.0 on this part of the build: link.exe kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib oldnames.lib /nologo /subsystem:windows /dll /debug /pdb:none /machine:I386 /opt:ref /opt:noicf /base:0x61000000 fdlibm/WINNT4.0_DBG.OBJ/fdlibm.lib \ /out:"WINNT4.0_DBG.OBJ/js32.dll" /pdb:none\ /implib:"WINNT4.0_DBG.OBJ/js32.lib" WINNT4.0_DBG.OBJ/jsapi.obj WINNT4.0_DBG.OBJ/jsarena.obj WINNT4.0_DBG.OBJ/jsarray.obj WINNT4.0_DBG.OBJ/jsatom.obj WINNT4.0_DBG.OBJ/jsbool.obj WINNT4.0_DBG.OBJ/jscntxt.obj WINNT4.0_DBG.OBJ/jsdate.obj WINNT4.0_DBG.OBJ/jsdbgapi.obj WINNT4.0_DBG.OBJ/jsdhash.obj WINNT4.0_DBG.OBJ/jsdtoa.obj WINNT4.0_DBG.OBJ/jsemit.obj WINNT4.0_DBG.OBJ/jsexn.obj WINNT4.0_DBG.OBJ/jsfun.obj WINNT4.0_DBG.OBJ/jsgc.obj WINNT4.0_DBG.OBJ/jshash.obj WINNT4.0_DBG.OBJ/jsinterp.obj WINNT4.0_DBG.OBJ/jslock.obj WINNT4.0_DBG.OBJ/jslog2.obj WINNT4.0_DBG.OBJ/jslong.obj WINNT4.0_DBG.OBJ/jsmath.obj WINNT4.0_DBG.OBJ/jsnum.obj WINNT4.0_DBG.OBJ/jsobj.obj WINNT4.0_DBG.OBJ/jsopcode.obj WINNT4.0_DBG.OBJ/jsparse.obj WINNT4.0_DBG.OBJ/jsprf.obj WINNT4.0_DBG.OBJ/jsregexp.obj WINNT4.0_DBG.OBJ/jsscan.obj WINNT4.0_DBG.OBJ/jsscope.obj WINNT4.0_DBG.OBJ/jsscript.obj WINNT4.0_DBG.OBJ/jsstr.obj WINNT4.0_DBG.OBJ/jsutil.obj WINNT4.0_DBG.OBJ/jsxdrapi.obj WINNT4.0_DBG.OBJ/prmjtime.obj LINK : fatal error LNK1181: cannot open input file "kernel32.lib" make[1]: *** [WINNT4.0_DBG.OBJ/js32.dll] Error 157 make: *** [all] Error 2

NOTE: I can build again if I revert js/src/config.mk from 3.10 to 3.9: =================================================================== RCS file: /cvsroot/mozilla/js/src/config.mk,v retrieving revision 3.10 retrieving revision 3.9 diff -r3.10 -r3.9 155,161d154 < < # Library name < LIB := lib < ifeq ($(CPU_ARCH), x86_64) < LIB := lib64 < endif < That was part of this checkin -

Need a fix for 1.4final. /be

I'm thinking the JS's build scripts use of $(LIB) is ill advised. LIB is also the list of directories used by the linker to find libraries. But it look as if the JS build system uses to determine the directory to put libraries for distribution. I'm not sure what the best way to fix things are. Just remove that change, and let the libs go into the default distribution directory as they currently are? Or rename lib to something like LIBDIST or otherwise less conflicting.

This is blocking me from publishing the next JS1.5 release candidate -

Cc'ing bryner for a little help, if he can help. /be

This should do the trick. Sorry I didn't see this before, but I got confused thinking I was looking at the original code when I was looking at the code after the patch. Bottom line, LIB was a poor choice of a name due to the conflicts, renamed to LIBDIR.

Comment on attachment 124127 [details] [diff] [review] Rename LIB to LIBDIR Looking for reviews for patch renaming LIB to LIBDIR

Comment on attachment 124127 [details] [diff] [review] Rename LIB to LIBDIR Thanks for fixing this. /be

Comment on attachment 124127 [details] [diff] [review] Rename LIB to LIBDIR This is a no-brainer for the 1.4 branch. Dbradley, can you do the checkin follow-thru? Thanks, /be

Yes, I'll get it checked in to the branch and the trunk

Comment on attachment 124127 [details] [diff] [review] Rename LIB to LIBDIR a=asa (on behalf of drivers) for checkin to 1.4.

LIB->LIBDIR patch checked into trunk

The new fix has enabled me to build the JS shell on Windows again! Both the debug and optimized shell built sucessfully. Furthermore, I ran the JS testsuite against the fix on Linux RH7.2, Mac OSX, and WinNT4.0 and observed no test regresssions in either the debug or optimized JS shell -

I tried checking into the 1.4 branch, but I don't have access. So if someone else can check this in, that would be great, or if I get access soon I'll go ahead and do it.

LIB->LIBDIR patch checked into branch now.

Rubber-stamp vrfy -

Adding verified1.4 keyword. That is, I have verified that the patches to these files are the same on the trunk and the -rMOZILLA_1_4_BRANCH: js/src/config.mk js/src/jsconfig.mk js/src/rules.mk The patch to the following config file is only on the trunk, however. That is normal, since it is only used in the build of the standalone JS shell: js/src/config/Linux_All.mk In fact, AFAIK, the directory mozilla/js/src/config/ is never tagged in Mozilla branches -