Closed Bug 163018 Opened 20 years ago Closed 19 years ago

Fix support for lib64 & x86-64 architectures

Categories

(Core :: JavaScript Engine, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: gbeauchesne, Assigned: gbeauchesne)

References

Details

(Keywords: fixed1.4)

Attachments

(1 file, 2 obsolete files)

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.
Attached file JS fixes for Linux/x86-64 (obsolete) —
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 -
Assignee: rogerl → khanson
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #95547 - Attachment is patch: false
Attachment #95547 - Attachment mime type: text/plain → application/macbinary
Attachment #95547 - Attachment mime type: application/macbinary → text/plain
The bottom of the file looks corrupted, too. Could one of the 
developers advise Gwenole on what might have gone wrong? Thanks -
Attached patch JS fixes for Linux/x86-64 (obsolete) — Splinter Review
Sorry, I hope it's OK this time.
Attachment #95547 - Attachment is obsolete: true
Attachment #95547 - Attachment mime type: text/plain → application/macbinary
Keywords: mozilla1.2, patch, review
line
 #else /* __alpha */
should read
 #else /* __alpha || __x86_64__ */


No longer blocks: 1.2
Attachment #95612 - Flags: review?(rogerl)
Attachment #95612 - Flags: review?(rogerl) → review?(shaver)
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.
Attachment #95612 - Flags: review?(shaver)
Attachment #95612 - Flags: review+
Attachment #95612 - Flags: approval1.4b?
Comment on attachment 95612 [details] [diff] [review]
JS fixes for Linux/x86-64

a=asa (on behalf of drivers) for checkin to 1.4b.
Attachment #95612 - Flags: approval1.4b? → approval1.4b+
Attachment #95612 - Flags: approval1.4?
Comment on attachment 95612 [details] [diff] [review]
JS fixes for Linux/x86-64

a=asa (on behalf of drivers) for checkin to 1.4
Attachment #95612 - Flags: approval1.4? → approval1.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.
Attachment #95612 - Attachment is obsolete: true
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.
Assignee: khanson → gbeauchesne
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
Flags: blocking1.4?
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
Attachment #124127 - Flags: superreview?(brendan)
Attachment #124127 - Flags: review?(seawood)
Comment on attachment 124127 [details] [diff] [review]
Rename LIB to LIBDIR

Thanks for fixing this.

/be
Attachment #124127 - Flags: superreview?(brendan) → superreview+
Attachment #124127 - Flags: review?(seawood) → review+
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
Attachment #124127 - Flags: approval1.4?
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.
Attachment #124127 - Flags: approval1.4? → approval1.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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking1.4?
Keywords: fixed1.4
Rubber-stamp vrfy -
Status: RESOLVED → VERIFIED
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 -
Keywords: verified1.4
Flags: testcase-
Duplicate of this bug: 249478
You need to log in before you can comment on or make changes to this bug.