How to handle linker options beginning with -f?

[Mark Mitchell]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

    Stan> No, the real blame falls on the NeXT hackers who made the
    Stan> changes without any apparent consideration of divergence

True.

    Stan> though not quite the same.  If -Wl, is always OK, then why
    Stan> not apply the reasoning to -l and -L and require users to
    Stan> say -Wl,-lfoo and -Wl,-L/usr/bar ? 

Because those are standard options supported by tons of compilers
(including, even, Windows compilers, for example).  Therefore, GCC has
been designed to avoid placing options in this namespace.  However, -f
(like -W) options are in GCC's standard option namespace.

    >>  Apple could simply provide a wrapper/shell-script/modified
    >> gcc.c that replaces `-framework' with `-Wl,-framework'.

    Stan> But that's not really any different from having a
    Stan> locally-modified version of GCC.

Qualitatively, you could make that argument.  But, practically, it's
very different.  It's not a fork in GCC if Apple provides a
shell-script wrapper.  Apple could deprecate -framework and provide
the wrapper, as a transition plan, and then eliminate it in favor of
-lframework or -Wl,-framework in the future.  Then, you could remove
the shell-script.

It's by no means a fork in the sense that EGCS of PGCC was a fork:
those forks modified core bits of the compiler in very significant
ways.  What we're talking about here is just a script.

    >> I suppose we could maybe make that an automatic process by
    >> using some kind of MD_REWRITE_COMMAND_LINE macro that allowed
    >> you to scan argv when gcc.c gets started and rewrite it as you
    >> saw fit.  That would seem reasonably sensible to me.  Then, you
    >> would just rewrite it before the rest of the driver saw it.
    >> And deprecate the heck out of it.

    Stan> That's the kind of thing I'm wondering about.  But since it
    Stan> entails a rewrite of the code we currently use locally, I
    Stan> don't want to get started on anything like that unless
    Stan> there's at least a remote chance it will be accepted.

I think I might be in favor of this, FWIW.

See my subsequent post, where I try to argue that we might be able to
eliminate other compatibility options from the driver proper.

Actually, on looking at this more, I don't see that there are many of
these.  In fact, there are no documented ones.  There are only a few
options that are documented as affecting the linker (like -shared and
-symbolic).

You said "if I'd added -Zfoo that would have been OK".  Can you point
me at where such code appears?  I believe it does, but I can't find it
now.  Thanks!

If there isn't any other such code, that would argue against
MD_REWRITE_COMMAND_LINE -- there would clearly be little need.

    Stan> As I write all this, it occurs to me that -l might actually
    Stan> be made into a valid equivalent for -framework, so I'm going
    Stan> to look into that too.

I don't understand that, but it sounds good. :-)

Yours,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com