Re: [RFC] Suggested replacement for specs and switch handling

["Anthony Green" <green at redhat dot com>]

Neil wrote:
> Is it possible to fulfill your needs another way?  rth suggested some
> of it could be done by wrapper scripts.

There are two complications with wrapper scripts.  I just don't know how
serious they are off hand.  One is that we would need both DOS batch file
scripts and Unix shell scripts.  I don't know how the two would interact on
a Windows machine.  The other complication is that you'd have to build the
scripts to make sure they knew about all of the internal paths built into
gcc.

> Run-time spec manipulation is
> inherently limited by whatever was compiled in to the driver anyway.
> Can you give an example of what spec magic you use as an embedded
> developer?

[I polled some of our internal users and am going to paraphrase them here --
hopefully I got it right :-) ]

- sometimes you don't want to use the default crt0.o.  There's no good way
of eliminating the default crt0.o from the link line without also tossing
out the crt{begin,end}.o, etc files along with it.  Some ports now have
an -mno-crt0 option to deal with this case, so we can get by without specs.

- sometimes we use specs file hacks to work around problems in compilers
deployed in the field (link order bugs, for instance).  This is extremely
convenient.

- grubbing through our internal specs files, it appears as if there's
nothing that can't be worked around using wrapper scripts, but they will
result in a less pleasant user experience. (also note issues above).

Personally, I believe we can go a long way by introducing `response files'
to GCC.  These are the @foo files used in the DOS world.  Having GCC look
for and use some default installed response file will help somewhat.  The
gcj driver is going to have to use something like this (and perhaps more) in
order to maintain the gcj/libgcj modularity we've come to enjoy.

AG