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

Status: RESOLVED FIXED

(Core :: js-ctypes, defect)

Description

[Josh Aas]

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'

Comment 1

[[e-mail]]

Attachment: test -n patch

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 2

[Josh Aas]

Comment on attachment 430801 [details] [diff] [review]
test -n patch

Doesn't fix the problem.

Comment 3

[[e-mail]]

Grumble.

Comment 4

[Justin Dolske [:Dolske]]

Note to self: 5feacacc0d09 is the last good changeset.

Comment 5

[Blake Winton (:bwinton) (:☕️)]

changeset 7e7ea9d499da (three after the one you listed, a.k.a. the one just before changeset 3cae91489a56) also worked for me.

Comment 6

[[e-mail]]

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.

Comment 7

[[e-mail]]

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.

Comment 8

[[e-mail]]

Attachment: patch v1

This might fix it. josh, dolske, could you please test?

Comment 9

[Josh Aas]

Patch doesn't apply to mozilla-central.

Comment 10

[[e-mail]]

It applies fine for me. It's against 2da8ac54d264. Can you clarify?

Comment 11

[[e-mail]]

(2da8ac54d264 was tip as of my last comment.)

Comment 12

[Josh Aas]

I think c82a85fe6cc3 broke it.

Comment 13

[[e-mail]]

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.

Comment 14

[[e-mail]]

Attachment: patch v2

Updated.

Comment 15

[Josh Aas]

patch v2 fixes the problem for me, thanks

Comment 16

[[e-mail]]

Attachment: patch v3

Propagate HOST_CC and CC to libffi's configure. Also tweaks the crosscompile by fully passing the --build/--host/--target info.

Comment 17

[[e-mail]]

Comment on attachment 431452 [details] [diff] [review]
patch v3

Got the right reviewer target, this time. :)

Comment 18

[[e-mail]]

Comment on attachment 431452 [details] [diff] [review]
patch v3

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

Landed as a bustage fix, pending review.

Comment 19

[[e-mail]]

Attachment: patch v4 [Checkin: Comment 18+22]

Gah, I forgot that our --host and --target are different to the traditional usage. So this patch dumps that change.

Comment 20

[Nomis101]

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.

Comment 21

[[e-mail]]

(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.

Comment 22

[Serge Gautherie (:sgautherie)]

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.