Closed
Bug 809404
Opened 12 years ago
Closed 3 years ago
Configuring libffi ignores CC/CXX from mozconfig and picks up the system compiler
Categories
(SeaMonkey :: Release Engineering, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ewong, Assigned: Callek)
References
Details
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
ewong
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
ewong
:
review+
|
Details | Diff | Splinter Review |
+++ This bug was initially created as a clone of Bug #748138 +++ I've been investigating an issue with some of our builds and libffi. As a result, I've noticed that libffi isn't actually picking up the compiler referenced in CC/CXX in the mozconfig, but is picking up the system mozconfig. So on our Firefox builders, in mozconfig.linux we have: CC=/tools/gcc-4.5-0moz3/bin/gcc CXX=/tools/gcc-4.5-0moz3/bin/g++ However, libffi configure is picking "gcc" i.e. the system one, which is actually version 4.1.1. That doesn't seem quite right, especially as I believe 4.1.1 supports a different default debug symbol set(?). You can see this happening if you read through the configure lines of any nightly build, e.g. https://tbpl.mozilla.org/php/getParsedLog.php?id=11120042&tree=Firefox&full=1
Reporter | ||
Comment 1•12 years ago
|
||
This is preventing our l10n-nightlies from building.
Reporter | ||
Comment 2•12 years ago
|
||
(In reply to Edmund Wong (:ewong) from comment #1) > This is preventing our l10n-nightlies from building. and by nightlies I mean OSX64 nightlies.
Reporter | ||
Comment 3•12 years ago
|
||
I tried this on sea-mini-osx64-4's existing .mozconfig, and it configures through.
Assignee | ||
Comment 4•12 years ago
|
||
Comment on attachment 679123 [details] [diff] [review] export CC/CXX to set the CC and CXX env variables. Actually build/macosx/universal/mozconfig sources macosx/common which exports CC and CXX (with clang) as used by tooltool The *real* fix [at least for us, short term] is to use tooltool in l10n jobs too.
Attachment #679123 -
Flags: review?(bugspam.Callek) → review-
Assignee | ||
Comment 5•12 years ago
|
||
I won't be able to get at this for a day or two to test. Can you verify it succeeds a checkconfig?
Attachment #679123 -
Attachment is obsolete: true
Attachment #679977 -
Flags: review?(ewong)
Reporter | ||
Updated•12 years ago
|
Attachment #679977 -
Flags: review?(ewong) → review+
Reporter | ||
Updated•12 years ago
|
Assignee: ewong → bugspam.Callek
Reporter | ||
Comment 6•12 years ago
|
||
Pushed to buildbotcustom: http://hg.mozilla.org/build/buildbotcustom/rev/5938a63af4de
Assignee | ||
Comment 7•12 years ago
|
||
This is needed to set the path right for this step, otherwise we don't find releng.manifest
Attachment #680226 -
Flags: review?(ewong)
Reporter | ||
Updated•12 years ago
|
Attachment #680226 -
Flags: review?(ewong) → review+
Reporter | ||
Comment 8•12 years ago
|
||
Pushed to buildbotcustom: http://hg.mozilla.org/build/buildbotcustom/rev/01c2c2191f84
This can also be an issue building firefox locally. I've been using clang on OS X, and something happened recently that made my gcc not work (this is an unrelated issue). As a result, when trying to build libffi, configure ignored mozconfig, tried to use gcc, and failed. Obviously, one answer is "fix whatever's wrong with gcc", but it would also be great if the build system always followed the compiler choices in mozconfig.
Comment 10•3 years ago
|
||
Let us assume it is fixed.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•