This is the mail archive of the
mailing list for the GCC project.
Re: How to handle linker options beginning with -f?
Mark Mitchell wrote:
> >>>>> "Stan" == Stan Shebs <email@example.com> writes:
> Stan> I agree, but it's a little late for that now. If no
> Stan> compromise is possible, then I won't bother trying to add
> Stan> these options into FSF GCC, and people can just get the
> Stan> fully functional compiler from Apple as they do now.
> I actually think this is the best solution.
However, this is not really a good idea, because it amounts to
endorsing forking. Apple is sufficiently staffed to support a
heavily divergent GCC forever, but it would be a loss for both Apple
and the FSF; if FSF GCC can't even build simple Mac programs, why
would anybody spend time on it? Easier to add features to Apple's
version of GCC only, and continue to diverge further.
> I don't think that we want to put support for this in the driver, and
> we certainly don't want to be in the position where "we sent out a
> bunch of kits that do it this way" becomes a justification for making
> changes to GCC that we wouldn't otherwise. Ideally, people would
> contact us *before* sending out the kits...
I mentioned the number of shipments because most people on this
list don't know very much about NeXT, Apple, Darwin and Mac OS X.
Apple is the only major system vendor to have committed to using
GCC as the primary compiler for all the systems they ship, and
that adds up to millions of systems. There is already a lot of
code in FSF GCC that nobody really wants to be there, but that's in
because the affected user base is too large to ignore. That's just
part of the system programming game, and the more successful you
are, the more of it you have to deal with.
In fact, there are many system-specific linker options in GCC sources,
for instance -Qy, -Qn, -YP, -assert*, -G, -rpath, -defsym, -R*, -z,
-K, -EB, -EL, -rdynamic, -call_shared, -exact_version, and so forth.
The common theme is that they don't start with 'f', and indeed if Apple's
option was called "-Zframework" or "-Qframework", I could stick it in
LINK_SPEC and no one would care (at least not until -Z* got used for
something else). The problem is that "-framework" is the most logical
name for the option, and it has been in use for many years already,
so I think it has just as much (or more) justification to be in GCC
as all those other linker options.