Re: How to handle linker options beginning with -f?

[Stan Shebs <shebs at apple dot com>]

Mark Mitchell wrote:
> 
> It's not really fair to blame us for causing a fork when it's Apple
> that wrote a bunch of code on its own.

No, the real blame falls on the NeXT hackers who made the changes
without any apparent consideration of divergence problems, but since
none of them are involved any longer, it's just a historical situation
that we need to resolve.  I've been quietly discarding or rewriting
many undesirable NeXT changes without ever mentioning them on this
list, so from my point of view it looks like I've been doing quite
a bit to re-converge.  (Credit should go to Apple mgmt btw, for
letting me spend months on an activity which has no immediate payoff.)

> Apple simply cannot expect to make changes and then argue that not
> accepting the changes will force a fork.

You're quite right, normally that shouldn't be possible, and the
rest of the team here will agree that I'm completely tiresome on the
subject of how we now have to do things in a way that is acceptable
for mainstream GCC.

>     Stan> Apple's option was called "-Zframework" or "-Qframework", I
>     Stan> could stick it in LINK_SPEC and no one would care (at least
> 
> Maybe.
> 
> We should actually figure out a better way to do this.
> 
> I'm not sure that we should add *any* more of these.  There's nothing
> wrong with asking people to use -Wl, in my opinion.

The idea of -framework is that it's the user-visible way of
specifying the use of a framework at runtime, similar to -l though
not quite the same.  If -Wl, is always OK, then why not apply the
reasoning to -l and -L and require users to say -Wl,-lfoo and
-Wl,-L/usr/bar ?  If the counterargument is "that's what users are
used to", that's why Apple users should be able to have -framework.

>     Stan> and it has been in use for many years already, so I think it
>     Stan> has just as much (or more) justification to be in GCC as all
>     Stan> those other linker options.
> 
> Apple could simply provide a wrapper/shell-script/modified gcc.c that
> replaces `-framework' with `-Wl,-framework'.

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

> 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.

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

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

Stan