http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |*-darwin*
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-04-12
CC| |iains at gcc dot gnu.org
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to a.h.jaffe from comment #4)
> (In reply to Marek Polacek from comment #3)
>
> "FSF GCC on Darwin does not create “fat” object files; it creates an object
> file for the single architecture that GCC was built to target"
indeed - see below.
> So I still think there's at least a "misfeature" in the sense that there
> should be a more graceful failure here, but in some sense the docs are right.
Hmm .. not sure how much leeway we have here (the general behaviour of the
driver is to allow multiple instances of flags [e.g. -O2 -O0] and take the last
one found). If we issued an error for multiple "-arch" it would be
inconsistent.
> However, a more general question: WHY doesn't FSF gcc have this capability?
1. The behaviour of the *underlying* GCC on Apple's installs is the same as
FSF-gcc - each version of the compiler generates output for one kind of
target/multilib combination and only one binary/invocation.
2. The "Apple GCC" is, in fact, an additional driver layer (you can find it as
driverdriver.c in thier sources). This 'driverdriver' invokes the underlying
compiler for each mentioned value of "arch" and then combines the outputs using
'lipo' to make a FAT files.
3. There is nothing to stop a distro (like macports or fink) from making a
similar provision; sometimes in the past, I built the "driverdriver" for my
own use. However, note that significant updating would be needed to deal with
recent versions of FSF-GCC.
4. Darwin support resources are very slim for FSF (we're all volunteers) - and
although it's a "nice to have" (definitely!!) I regret not high on the priority
list compared with bug fixes.
5. We do accept -arch on x86: -arch i386 gets mapped => -m32 and -arch x86_64
-> -m64. The last one you place on the c/l will be in force (and there's NO
support for the ppc equivalent at present).
SO…
… re-filing this as an enhancement request.
Patches welcome!
