163018 - Fix support for lib64 & x86-64 architectures

Status: VERIFIED FIXED

(Core :: JavaScript Engine, enhancement)

Description

[Gwenole Beauchesne]

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.

Comment 1

[Gwenole Beauchesne]

Attachment: JS fixes for Linux/x86-64

Comment 2

[Gwenole Beauchesne]

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.

Comment 3

[Phil Schwartau]

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

Comment 4

[Phil Schwartau]

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

Comment 5

[Gwenole Beauchesne]

Attachment: JS fixes for Linux/x86-64

Sorry, I hope it's OK this time.

Comment 6

[Jerome Lacoste]

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

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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 8

[Asa Dotzler [:asa]]

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 9

[Asa Dotzler [:asa]]

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 10

[timeless]

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.

Comment 11

[Phil Schwartau]

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

Comment 12

[timeless]

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

Comment 13

[Phil Schwartau]

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

Comment 14

[Phil Schwartau]

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 -

Comment 15

[Brendan Eich [:brendan]]

Need a fix for 1.4final.

/be

Comment 16

[David Bradley]

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.

Comment 17

[Phil Schwartau]

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

Comment 18

[Brendan Eich [:brendan]]

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

/be

Comment 19

[David Bradley]

Attachment: Rename LIB to LIBDIR

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 20

[David Bradley]

Comment on attachment 124127 [details] [diff] [review]
Rename LIB to LIBDIR

Looking for reviews for patch renaming LIB to LIBDIR

Comment 21

[Brendan Eich [:brendan]]

Comment on attachment 124127 [details] [diff] [review]
Rename LIB to LIBDIR

Thanks for fixing this.

/be

Comment 22

[Brendan Eich [:brendan]]

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

Comment 23

[David Bradley]

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

Comment 24

[Asa Dotzler [:asa]]

Comment on attachment 124127 [details] [diff] [review]
Rename LIB to LIBDIR

a=asa (on behalf of drivers) for checkin to 1.4.

Comment 25

[David Bradley]

LIB->LIBDIR patch checked into trunk

Comment 26

[Phil Schwartau]

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 -

Comment 27

[David Bradley]

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.

Comment 28

[David Bradley]

LIB->LIBDIR patch checked into branch now.

Comment 29

[Phil Schwartau]

Rubber-stamp vrfy -

Comment 30

[Phil Schwartau]

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 -