Closed Bug 612809 Opened 9 years ago Closed 9 years ago

Unable to cross compile 32-bit shells on Mac OS X 10.6

Categories

(Core :: JavaScript Engine, defect, blocker)

x86
macOS
defect
Not set
blocker

Tracking

()

RESOLVED FIXED

People

(Reporter: gkw, Assigned: paul.biggar)

References

Details

(Keywords: regression, Whiteboard: fixed-in-tracemonkey)

Attachments

(2 files)

Recently, I am unable to cross compile 32-bit shells on 10.6. The following is the compilation command:

CC="gcc-4.2 -arch i386" CXX="g++-4.2 -arch i386" HOST_CC="gcc-4.2" HOST_CXX="g++-4.2" RANLIB=ranlib AR=ar AS=$CC LD=ldSTRIP="strip -x -S" CROSS_COMPILE=1sh /Users/fuzz1/Desktop/jsfunfuzz-dbg-32-tm-57557-7b8898c9b54c/compilePath/configure --target=i386-apple-darwin8.0.0 --enable-debug --disable-optimize --disable-tests

I am able to compile 64-bit shells, though.

The error shown is:

jscpucfg.cpp:48:21: error: prtypes.h: No such file or directory

===

hg bisection shows this as the cause:

changeset:   56649:b1094f628602
user:        Paul Biggar
date:        Thu Oct 28 12:23:00 2010 -0700
summary:     Bug 605133 - Sync configure.in changes from the last two years to js/src/configure.in.
blocking2.0: --- → ?
Yes, bug 605133 broke CROSS_COMPILE, sorry about that. It's being fixed as part of bug 608696. However, that has different symptoms, so let's revisit this after bug 608696 is fixed. (It should be fixed today, but it should work if you export CROSS_COMPILE=1 if you need it sooner).
This was covered by bug 605133 comment 22, right?  Did that just get ignored?  :(
(In reply to comment #2)
> This was covered by bug 605133 comment 22, right?  Did that just get ignored? 
> :(

I didn't ignore it, I though I had fixed it. The symptom was about js-config not being built, and I thought it was the same as a different problem with js-config not being built, which I fixed. I didn't realize there was a second problem.
(In reply to comment #1)
> Yes, bug 605133 broke CROSS_COMPILE, sorry about that. It's being fixed as part
> of bug 608696. However, that has different symptoms, so let's revisit this
> after bug 608696 is fixed. (It should be fixed today, but it should work if you
> export CROSS_COMPILE=1 if you need it sooner).

Oh, you were exporting CROSS_COMPILE=1.

The fix in bug 608696 just exports CROSS_COMPILE=1, and I confess I don't understand why it fixes it while setting CROSS_COMPILE=1 did not. (I assume your setting of CROSS_COMPILE=1sh was a cut-and-paste error in the bug report).
I think this should be fixed (I'd dup this but the symptoms are different). Gary, is this fixed by http://hg.mozilla.org/tracemonkey/rev/301b97a20042?
Attached file compile output
My local i386 cross-compile on Mac OS X 10.6 is broken by the tm merge. Here is a log. One thing that stands out - I don't think "ARMAssembler.cpp" is supposed to be getting compiled at all.
(In reply to comment #5)
> I think this should be fixed (I'd dup this but the symptoms are different).
> Gary, is this fixed by http://hg.mozilla.org/tracemonkey/rev/301b97a20042?

Yes, Paul, it seems to be fixed. :) I don't get Josh's error though.
(In reply to comment #6)
> Created attachment 491450 [details]
> compile output
> 
> My local i386 cross-compile on Mac OS X 10.6 is broken by the tm merge. Here is
> a log. One thing that stands out - I don't think "ARMAssembler.cpp" is supposed
> to be getting compiled at all.

I don't know anything about ARMAssembler.cpp, but I think it's a red herring (it says it has no symbols anyway...)

Looking at your logs, which symbols are which cputype? Are your new symbols x86_64 or your old ones?

Does a clean build work?
(In reply to comment #8)
> Looking at your logs, which symbols are which cputype? Are your new symbols
> x86_64 or your old ones?
> 
> Does a clean build work?

Ignore this, I've figured it out.
cross_compiling is overwritten by autoconf macros, so the correct solution is to set CROSS_COMPILE directly.

I think part of the problem here is that everyone uses different configure lines to cross-compile. Of all the bugs on this, I'm not sure any two have used the same configure line.
Assignee: general → pbiggar
Attachment #491495 - Flags: review?(ted.mielczarek)
I'm not sure whether to apply this to TM, and ask for a merge, or apply directly to M-C?
Attachment #491495 - Attachment is patch: true
Attachment #491495 - Attachment mime type: application/octet-stream → text/plain
Attachment #491495 - Flags: review?(ted.mielczarek) → review+
I don't have commit privileges for mozilla-central, so a motivated person should feel free to push attachment 491495 [details] [diff] [review] for me (attempts to finds a committer has thus far failed).
(In reply to comment #14)
> I don't have commit privileges for mozilla-central, so a motivated person
> should feel free to push attachment 491495 [details] [diff] [review] for me (attempts to finds a
> committer has thus far failed).

It should get to m-c on the next merge. Is there some reason you need it to land there sooner?
Hi Paul, I now get this error when cross compiling 32-bit shells on Ubuntu Linux 10.04 64-bit, not sure if it's related:

configure command:

CC="gcc -m32" CXX="g++ -m32" AR=ar sh configure --target=i686-pc-linux --disable-tests --disable-optimize --enable-debug

Error is:
jscpucfg.cpp:48:21: error: prtypes.h: No such file or directory
jscpucfg.cpp:81:2: error: #error "Endianess not defined."
So current TM tip (which includes this patch), when I try to do this:

env CC="gcc-4.2 -arch i386" CXX="g++-4.2 -arch i386" AR=ar CROSS_COMPILE=1 ../configure --enable-optimize --disable-debug --target=i386-apple-darwin9.2.0 --enable-macos-target=10.5

for the shell I get:

../jscpucfg.cpp:48:21: error: prtypes.h: No such file or directory
(In reply to comment #15)
> It should get to m-c on the next merge. Is there some reason you need it to
> land there sooner?

Because the build is broken for people who cross-compile on M-C.

(With this fix, only the shell is broken for cross-compiling folk, and not in all cases).
(In reply to comment #14)
> I don't have commit privileges for mozilla-central, so a motivated person
> should feel free to push attachment 491495 [details] [diff] [review] for me (attempts to finds a
> committer has thus far failed).

I should mention that OSX will need to be clobbered using https://build.mozilla.org/clobberer/.
The final parts of this are fixed as part of bug 608696.
blocking2.0: ? → final+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
blocking2.0: final+ → ?
Keywords: checkin-needed
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
blocking2.0: ? → ---
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.