Closed Bug 550646 Opened 12 years ago Closed 12 years ago

32-bit Mac OS X builds cross-compiled on Mac OS X broken

Categories

(Core :: js-ctypes, defect)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.9.3a3

People

(Reporter: jaas, Assigned: dwitte)

References

Details

Attachments

(1 file, 4 obsolete files)

32-bit Intel builds created on Mac OS X 10.6 are broken. This is a big problem for any developers working on 10.6. I suspect this has to do with one of these commits:

http://hg.mozilla.org/mozilla-central/rev/3cae91489a56
http://hg.mozilla.org/mozilla-central/rev/39027a970ec3

=============

ar cr libjsctypes.a Function.o Library.o Module.o  debug.o prep_cif.o types.o raw_api.o java_raw_api.o closures.o ffi.o darwin.o ffi64.o darwin64.o
ranlib: archive member: libjsctypes.a(debug.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(prep_cif.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(types.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(raw_api.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(java_raw_api.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(closures.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(ffi.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(darwin.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(ffi64.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(darwin64.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib libjsctypes.a
ranlib: archive member: libjsctypes.a(debug.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(prep_cif.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(types.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(raw_api.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(java_raw_api.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(closures.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(ffi.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(darwin.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(ffi64.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: archive member: libjsctypes.a(darwin64.o) cputype (16777223) does not match previous archive members cputype (7) (all members must match)
ranlib: for architecture: x86_64 file: libjsctypes.a(raw_api.o) has no symbols
ranlib: for architecture: x86_64 file: libjsctypes.a(java_raw_api.o) has no symbols
ranlib: for architecture: x86_64 file: libjsctypes.a(ffi.o) has no symbols
ranlib: for architecture: x86_64 file: libjsctypes.a(darwin.o) has no symbols
make[4]: *** [libjsctypes.a] Error 1
make[4]: *** Deleting file `libjsctypes.a'
Depends on: 538216
Attached patch test -n patch (obsolete) — Splinter Review
Hmm. We can check whether it's the 'test -n' changes with this patch. If not, I'll have to go through the libffi changesets and guess.

Josh, feel like testing this? :)
Comment on attachment 430801 [details] [diff] [review]
test -n patch

Doesn't fix the problem.
Grumble.
Note to self: 5feacacc0d09 is the last good changeset.
changeset 7e7ea9d499da (three after the one you listed, a.k.a. the one just before changeset 3cae91489a56) also worked for me.
Ah, I know what's going on. One of my patches switched libffi from using our configure's config.cache to having its own independent one. Which is sane. But obviously, their configure is having a hard time deducing what to do.

Some combination of configure flags and/or CFLAGS will fix this.
CC="gcc-4.2 -arch i386"
CXX="g++-4.2 -arch i386"

Those two lines in the mozconfig are responsible for making our crosscompile work. We need to propagate those to libffi.
Attached patch patch v1 (obsolete) — Splinter Review
This might fix it. josh, dolske, could you please test?
Patch doesn't apply to mozilla-central.
It applies fine for me. It's against 2da8ac54d264. Can you clarify?
(2da8ac54d264 was tip as of my last comment.)
I think c82a85fe6cc3 broke it.
Um, but that landed early thismorning, well after I posted the patch here. Did you have it applied locally or something?

Anyway, I'll update.
Attached patch patch v2 (obsolete) — Splinter Review
Updated.
Attachment #430801 - Attachment is obsolete: true
Attachment #431282 - Attachment is obsolete: true
patch v2 fixes the problem for me, thanks
Attached patch patch v3 (obsolete) — Splinter Review
Propagate HOST_CC and CC to libffi's configure. Also tweaks the crosscompile by fully passing the --build/--host/--target info.
Assignee: nobody → dwitte
Attachment #431406 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #431452 - Flags: review?
Comment on attachment 431452 [details] [diff] [review]
patch v3

Got the right reviewer target, this time. :)
Attachment #431452 - Flags: review? → review?(ted.mielczarek)
Comment on attachment 431452 [details] [diff] [review]
patch v3

http://hg.mozilla.org/mozilla-central/rev/7089c29da493

Landed as a bustage fix, pending review.
Gah, I forgot that our --host and --target are different to the traditional usage. So this patch dumps that change.
Attachment #431452 - Attachment is obsolete: true
Attachment #431495 - Flags: review?(ted.mielczarek)
Attachment #431452 - Flags: review?(ted.mielczarek)
Oh, and I thought it's me. I run into the same problem for Thunderbird Trunk two days ago and could't find a reason. I've tried it today and I still see a lot of  "ranlib: blah-blah has no symbols". But it doesn't stop with the libjsctypes error anymore.
(In reply to comment #20)
> Oh, and I thought it's me. I run into the same problem for Thunderbird Trunk
> two days ago and could't find a reason. I've tried it today and I still see a
> lot of  "ranlib: blah-blah has no symbols". But it doesn't stop with the
> libjsctypes error anymore.

The 'no symbols' thing is normal; just a warning.
Attachment #431495 - Flags: review?(ted.mielczarek) → review+
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 431495 [details] [diff] [review]
patch v4
[Checkin: Comment 18+22]


http://hg.mozilla.org/mozilla-central/rev/d7c8a5ced609
Followup fix to revert --host/--target changes.
Attachment #431495 - Attachment description: patch v4 → patch v4 [Checkin: Comment 18+22]
Flags: in-testsuite-
Target Milestone: --- → mozilla1.9.3a3
You need to log in before you can comment on or make changes to this bug.