Closed Bug 700772 Opened 14 years ago Closed 14 years ago

Configure should clearly reject non-Apple GCC on Darwin

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 787931

People

(Reporter: gps, Unassigned)

References

Details

In bug 700524, it was decided we won't support non-Apple GCC (i.e. stock GCC) on Darwin. configure should reflect this decision by failing (faster) if a non-Apple GCC is detected. Currently, configure detects stock GCC on Darwin and goes on its merry way. Things blow up later in the configure in js/ (*after* the original configure completes, *after* Makefiles are generated) with an error message that doesn't clearly indicate the choice of a compiler is the culprit: checking for the size of void*... configure: error: No size found for void* configure: error: /Users/gps/src/services-central-git/js/src/configure failed for js/src *** Fix above errors and then restart with "make -f client.mk build" I'm not sure how exactly this could be implemented. We /might/ be able to require the word 'apple' to appear in `gcc --version`. That would work on OS X 10.7. Not sure how long "apple" has been in Apple's GCC version strings. Can someone with an old OS X verify? We could also reject GCC versions greater than 4.2.x on Darwin. Presumably, Apple won't be releasing any GCC versions greater than 4.2 since they stopped shipping GCC in Xcode 4.2. There is a chance a future version of the LLVM translator (which installs itself as gcc) could identify itself as GCC 4.3, 4.4, etc. This would miss versions less than 4.2, so it is suboptimal. Any ideas?
Does stock GCC define __APPLE__?
Do you mean "on mac" or "on Darwin" here? We have a tier-3 build configuration of a Darwin kernel with X that still muddles along.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > Do you mean "on mac" or "on Darwin" here? We have a tier-3 build > configuration of a Darwin kernel with X that still muddles along. In that case, I probably mean "on Mac." Or, if the Darwin configuration is using Apple's GCC, then I probably do mean "on Darwin." So, uh, I dunno.
What is wrong with the vanilla gcc? From the other bug report, it looks like someone is trying to use CFLAGS="-arch i386 -arch x86_64" with a vanilla gcc. That's just plain wrong and their fault for trying. If a user wants to build firefox for just i386, there's no reason they shouldn't be able to use vanilla gcc. I suggest you just bail out early if they try to build a *FAT* version with a compiler that doesn't support -arch rather than doing so unconditionally.
The important issue here is Apple's SDK (i.e. headers) and libraries. Of course vanilla gcc should work on a vanilla BSD/Darwin, but right now we assume $target ~= darwin means recent MacOS X with Apple's toolchain.
I don't think the issue is at all about the SDK. The vanilla gcc uses the exact same SDK as the Apple toolchain.
Also, your terminology is still wrong here. It's fine if you assume $target ~= darwin means Mac OS X (unless you plan on shipping an iOS app). The problem is that you're assuming $target ~= darwin means that the application is distributed as a bundle or that the toolkit being used is Cocoa. The bundle and toolkit options are distinct from the FS layout and toolkit options.
To clarify (AFAICT): 1) The current build system assumes "darwin" == "MacOS X" == "having Cocoa" == "Apple's toolchain." These are poor assumptions, but they're what we have currently. 2) The current tree fails to build on Darwin/OS X with vanilla GCC (because of #1). Because we only currently work on a very specific configuration (albeit the most popular one), this bug merely proposes adding detection to configure to catch the known busted configurations. Currently, as stated in the initial commit, we get nebulous and unhelpful error messages. This isn't very user friendly. If/when we support vanilla GCC on Darwin or OS X or any variant thereof, we can adjust this configure rule appropriately. Downstream consumers building on Darwin using vanilla GCC (if there are any) will have to patch around this. But, they must patch around current build system assumptions today, so the incremental cost should be low. I'm all for supporting vanilla GCC on any platform, Darwin-derived or not. If someone submits a patch, fair game. As for the current assumptions from #1, those should ideally be cleaned up. I suppose a bug should be filed for that. Jeremy: you appear to know the problem space. Can you file it?
(In reply to Gregory Szorc [:gps] from comment #8) > To clarify (AFAICT): > > 1) The current build system assumes "darwin" == "MacOS X" == "having Cocoa" > == "Apple's toolchain." These are poor assumptions, but they're what we have > currently. Well then how difficult is it so *UNDO* that? These assumptions didn't exist in master on 2011.08.20, but they did for the first tag after that (Around 9/20 IIRC). I haven't bisected to figure out what introduced the change. > 2) The current tree fails to build on Darwin/OS X with vanilla GCC (because > of #1). I fail to see why that is the case. Vanilla gcc can build bundles and work with frameworks just fine. *WHAT* is the problem that you are facing? I fail to see any specifics, just "vanilla gcc doesn't work" ... can someone please tell me *WHY* they think it doesn't work, and I may be able to provide you with a solution. As far as I can tell, the only thing that I have seen is the missing support for the apple driver-driver (ie the -arch flag), and that's not really an issue as far as I'm concerned since building fat isn't a requirement and up to the person providing $CC and $CFLAGS. If they provide $CFLAGS that $CC doesn't support, that's their fault, and ./configure's AC_PROG_CC will catch that, so this bug is already handled for us by autoconf. > As for the current assumptions from > #1, those should ideally be cleaned up. I suppose a bug should be filed for > that. Jeremy: you appear to know the problem space. Can you file it? I've filed multiple over the past few years as they cropped up, but some time between August 20 and Sept 20, someone majorly broke master. I filed about 5 bug reports around late Sept/early Oct to fix the issues that I found, but I then gave up trying to fix the rest.
Also, of the bugs that I filed against the Sept 27 tag, only one remains open: #691135 ... When I have more time on my hands, I'll try ti fix the rest of the fallout in recent master, but the 9/27 tag was just too much to handle in one sitting.
Also, wrt the initial comment: checking for the size of void* ... What does config.log say about the failure. Why is it failing that check? That should actually work on vanilla gcc since it only supports building one arch at a time. That configure check is bad for fat binaries since the values can be differnet for differnet slices. You should use sizeof(void *) in the code directly rather than using autoconf and a CPP macro ... otherwise, you'll have an i386 slice think that sizeof(void *) is 8 because ./configure checked the x86_64 slice's results.
Jeremy: I didn't realize we are dealing with a regression. I kinda assumed the current behavior had existed for a while. I can definitely sympathize with your position. IMO you are right to question this bug and bug 700524. I suspect the regression was accidental (since your patches have been getting merged in). So, I suspect there will be support to fix the regression and restore support for building on Darwin/X11. That being said, we'll still need to make a decision on supporting vanilla GCC on MacOS X/Cocoa/foo, which is different from Darwin/X11/bar (what IS the most proper terminology here?). Again, if we can support it, great. If not, let's make that decision and catch it in configure. w.r.t. the "size of void *" failing, many of the configure tests are failing on vanilla GCC on OS X because '-arch' is in the default CFLAGS on all Darwin platforms (at least in how a simple .mozconfig makes things). For some reason, this particular test causes configure to abort where other configure tests simply continued on with improper detections.
I don't see "-arch" anywhere in configure. Perhaps it's just your mozconfig that's incorrect?
Yeah, I don't think you should add -arch to any CFLAGS by default. That should be up to the person running ./configure (or by extension the mozconfig file). It might make sense for your default builds to be x86_64/i386 FAT, but don't set that because someone might want to build for ppc (yes, I know it's not supported), or just x86_64, or ... Hopefully that should be a simple fix of removing '-arch i386 -arch x86_64' out of some mozconfig file
It shouldn't be up to the person running configure to make the default build do the right thing (fat bundle, Cocoa, Quicktime, etc.) on MacOS X. Configuring the build based on the target system is what configure is for. The issue is making it ALSO do the right thing on upstream-gcc-on-macos, darwin/X11/gtk, GNU/Darwin, or whatever other targets folks care to maintain.
(Or not, I guess, as suggested by the bug title. I'm generally in favour of soft failures; they're easier for the unfamiliar to fix. However, it at least sounds like we should be "Checking if $CC supports -arch i386" &c.)
Oops. Having looked at configure some more, it seems the default macos build isn't fat (and doesn't need -arch) This is set by the mozconfig's in build/macosx/ Is that what we use for official builds?
That's what we use for official builds, yes, but it's not used by default if you do a local build.
Ok, thanks. Sorry for confusing things.
(In reply to Ralph Giles (:rillian) from comment #15) > It shouldn't be up to the person running configure to make the default build > do the right thing (fat bundle, Cocoa, Quicktime, etc.) on MacOS X. > Configuring the build based on the target system is what configure is for. Yeah, it can do the right thing for fat, cocoa, quicktime, etc, but arch CFLAGS are something that should NOT be set by configure. No other autoconf project that I'm aware of (other than wine) forces -arch or -m32 or similar. Why should mozilla? Since the '-arch i386' bits are in the mozconfig which are only used for the official builds, I don't see any actual problem here. Was -arch i386 getting into the reporter's CFLAGS from some other mechanism?
I would says that configure should check for *features*. Something simple as trying to compile a program that uses blocks should be sufficient.
-arch is getting into the CFLAGS during a vanilla build without any crazy .mozconfig. My .mozconfig: http://gps.pastebin.mozilla.org/1379418 Relevant make output: make tier_nspr tier_nspr: nsprpub config/nspr make -C nsprpub make -C config export /usr/local/bin/ccache /usr/local/bin/gcc-4.6 -arch x86_64 -o now.o -c -Wall -fno-common -isysroot /Developer/SDKs/MacOSX10.7.sdk -O2 -g -fPIC -UNDEBUG -DDEBUG_gps -DMOZILLA_CLIENT=1 -DDEBUG=1 -DHAVE_VISIBILITY_HIDDEN_ATTRIBUTE=1 -DHAVE_VISIBILITY_PRAGMA=1 -DXP_UNIX=1 -DDARWIN=1 -DHAVE_BSD_FLOCK=1 -DHAVE_SOCKLEN_T=1 -DXP_MACOSX=1 -DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM /Users/gps/src/services-central-git/nsprpub/config/now.c In nsprpub/config/automake.mk, we see: CC = /usr/local/bin/ccache /usr/local/bin/gcc-4.6 -arch x86_64 See line ~1365 in nsprpub/configure.in for the source. This needs fixed. Even if we fix/remove that, the js/ tree runs into linking issues. See bug 700524.
As of bug 787931 we require Clang on Darwin. So, there's nothing to do here since this involved GCC only.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.