Closed
Bug 778035
Opened 12 years ago
Closed 12 years ago
OSX64 builds failing due to missing CC/CXX exports
Categories
(SeaMonkey :: Release Engineering, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ewong, Assigned: ewong)
References
Details
Attachments
(3 files, 3 obsolete files)
883 bytes,
patch
|
Callek
:
review+
|
Details | Diff | Splinter Review |
889 bytes,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
521 bytes,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
Bug 775539 is to setup OSX boxes to use clang instead of gcc; but, clang has not been set up on the OSX machines. In the meantime, the OSX64 boxes are not building due to missing CC/CXX exports. m-c's /build/macosx/common and c-c's build/macosx/common currently looks like this: if [ -d "$topsrcdir/clang" ]; then # mozilla-central based build export CC=$topsrcdir/clang/bin/clang export CXX=$topsrcdir/clang/bin/clang++ elif [ -d "$topsrcdir/../clang" ]; then # comm-central based build export CC=$topsrcdir/../clang/bin/clang export CXX=$topsrcdir/../clang/bin/clang++ fi Since SeaMonkey doesn't have clang installed, the if and elif blocks don't apply and thusly CC and CXX are not set.
Assignee | ||
Comment 1•12 years ago
|
||
The rationale for this patch is to ensure that the c-c patch to this bug is the same as the one in m-c's build/macosx/common so that during the check of macosx/common, it would not fail. In theory, this patch should not affect FF's build.
Attachment #646462 -
Flags: review?(khuey)
Assignee | ||
Comment 2•12 years ago
|
||
Attachment #646465 -
Flags: review?(bugspam.Callek)
Assignee | ||
Updated•12 years ago
|
Attachment #646462 -
Attachment description: Add else block to set CC/CXX for systems that don't have clang. → Add else block to set CC/CXX for systems that don't have clang. (m-c)
Assignee | ||
Updated•12 years ago
|
Attachment #646462 -
Flags: feedback?(bugspam.Callek)
Comment on attachment 646462 [details] [diff] [review] Add else block to set CC/CXX for systems that don't have clang. (m-c) Review of attachment 646462 [details] [diff] [review]: ----------------------------------------------------------------- I don't know much about Mac, sorry.
Attachment #646462 -
Flags: review?(khuey) → review?(ted.mielczarek)
Comment 4•12 years ago
|
||
I agree that we should be doing something to make this suck less. I'm not sure if falling back to GCC is really what we want. I'd prefer to make the mozconfig error if CC/CXX are not set. You could just set CC/CXX in your build environment, then. My reasoning is that we don't really want to support GCC 4.2 on Mac much longer, so I'd rather not encode it into the mozconfigs.
Comment 5•12 years ago
|
||
(In reply to Ted Mielczarek [:ted] from comment #4) > I agree that we should be doing something to make this suck less. I'm not > sure if falling back to GCC is really what we want. I'd prefer to make the > mozconfig error if CC/CXX are not set. You could just set CC/CXX in your > build environment, then. > > My reasoning is that we don't really want to support GCC 4.2 on Mac much > longer, so I'd rather not encode it into the mozconfigs. The problem is that until SeaMonkey gets tooltool up, we need to have matching files from comm-* to mozilla-* otherwise the check-sync-dirs fails. Would you be ok with this as a TEMPORARY solution until I can get the clang stuff working on our systems?
Comment 6•12 years ago
|
||
Can't you just export CC/CXX to the paths to GCC in the meantime? We're not planning on unsupporting GCC 4.2 immediately, so that should work fine.
Comment 7•12 years ago
|
||
Comment on attachment 646462 [details] [diff] [review] Add else block to set CC/CXX for systems that don't have clang. (m-c) Review of attachment 646462 [details] [diff] [review]: ----------------------------------------------------------------- I'll let Rafael make the final call here.
Attachment #646462 -
Flags: review?(ted.mielczarek) → review?(respindola)
Comment on attachment 646462 [details] [diff] [review] Add else block to set CC/CXX for systems that don't have clang. (m-c) Using /usr/bin/gcc is definitely *NOT* OK. That is llvm-gcc, which is not supported and is know to be broken. Given that it took releng just a few hours in the previous bugs to setup tooltool for a given branch, I think it would be better to just ask them to set it up for seamonkey. If there is a good reason why that is not possible, you should use /usr/bin/clang or as a very last resort /usr/bin/gcc-4.2.
Attachment #646462 -
Flags: review?(respindola) → review-
Comment 9•12 years ago
|
||
(In reply to Rafael Ávila de Espíndola (:espindola) from comment #8) > Comment on attachment 646462 [details] [diff] [review] > Add else block to set CC/CXX for systems that don't have clang. (m-c) > > Using /usr/bin/gcc is definitely *NOT* OK. That is llvm-gcc, which is not > supported and is know to be broken. Fair enough, but it *might* be different on SeaMonkey machines, we'll have to verify that. > Given that it took releng just a few hours in the previous bugs to setup > tooltool for a given branch, I think it would be better to just ask them to > set it up for seamonkey. Well SeaMonkey is managed by a completely different system and not MoCo releng, and doesn't yet have tooltool support setup. *AND* we don't have a tooltool repository available for us yet (since the current tooltool repo for MoCo has private bits in it, the public mirror of public bits needs coding work to even be useable or to have stuff on it) > If there is a good reason why that is not possible, you should use > /usr/bin/clang or as a very last resort /usr/bin/gcc-4.2. Until we can setup tooltool I think its safer to use gcc-*, unless it breaks at some point. The main point here is to keep stuff working (right) for SeaMonkey, since the in-tree mozconfigs are designed for official machines, not end-users, hardcoding expectations has been ok so far :-)
Assignee | ||
Comment 10•12 years ago
|
||
Attachment #646462 -
Attachment is obsolete: true
Attachment #646462 -
Flags: feedback?(bugspam.Callek)
Attachment #649920 -
Flags: review?(respindola)
Assignee | ||
Comment 11•12 years ago
|
||
Attachment #646465 -
Attachment is obsolete: true
Attachment #646465 -
Flags: review?(bugspam.Callek)
Attachment #649921 -
Flags: review?(bugspam.Callek)
Assignee | ||
Updated•12 years ago
|
Attachment #649920 -
Flags: review?(respindola)
Assignee | ||
Comment 12•12 years ago
|
||
Attachment #649920 -
Attachment is obsolete: true
Attachment #649923 -
Flags: review?(respindola)
> Well SeaMonkey is managed by a completely different system and not MoCo > releng, and doesn't yet have tooltool support setup. *AND* we don't have a > tooltool repository available for us yet (since the current tooltool repo > for MoCo has private bits in it, the public mirror of public bits needs > coding work to even be useable or to have stuff on it) Oh, I was under the impression that (like Thunderbird), SeaMonkey was using releng's infrastructure. > > If there is a good reason why that is not possible, you should use > > /usr/bin/clang or as a very last resort /usr/bin/gcc-4.2. > > Until we can setup tooltool I think its safer to use gcc-*, unless it breaks > at some point. The main point here is to keep stuff working (right) for > SeaMonkey, since the in-tree mozconfigs are designed for official machines, > not end-users, hardcoding expectations has been ok so far :-) Exactly, they are designed to work with releng's infrastructure. If you are not using that, you should not be using these files.
Attachment #649923 -
Flags: review?(respindola) → review-
Comment 14•12 years ago
|
||
Comment on attachment 649923 [details] [diff] [review] Add else block to set CC/CXX for systems that don't have clang. (m-c) (v2) Review of attachment 649923 [details] [diff] [review]: ----------------------------------------------------------------- Okay. In the interest of getting SeaMonkey builds unblocked I'm going to r+ this patch. The caveat is that we are going to unsupport gcc-4.2 after Firefox 17 branches (the next cycle), and this change is going to be backed out when that happens. That does give you a few weeks to get your build environment in order, so hopefully that's enough to get you where you need to be.
Attachment #649923 -
Flags: review- → review+
To be committed 2012-08-27 after the merge.
Attachment #650235 -
Flags: review?(ted.mielczarek)
Comment 16•12 years ago
|
||
Comment on attachment 650235 [details] [diff] [review] revert it Review of attachment 650235 [details] [diff] [review]: ----------------------------------------------------------------- This is fine, but can you file a new bug for this? (If we already have a "stop supporting GCC-4.2" bug, you could make it block that one.)
Attachment #650235 -
Flags: review?(ted.mielczarek) → review+
Blocks: 781302
Done. Do you want me to move the patch to 781302 or leave it here?
Comment 18•12 years ago
|
||
For sanity you should probably move it there. You can just propagate my r+ there.
Updated•12 years ago
|
Attachment #649921 -
Flags: review?(bugspam.Callek) → review+
Assignee | ||
Comment 19•12 years ago
|
||
Pushed to m-c: https://hg.mozilla.org/mozilla-central/rev/08e0e3b95f03
Assignee | ||
Comment 20•12 years ago
|
||
Pushed to comm-central: http://hg.mozilla.org/comm-central/rev/2019e8845fbf
Assignee | ||
Updated•12 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 21•12 years ago
|
||
Try run for 513eaff31bfd is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=513eaff31bfd Results (out of 16 total builds): exception: 16 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/czchen@gmail.com-513eaff31bfd
You need to log in
before you can comment on or make changes to this bug.
Description
•