Re: response file support in GCC

[Gary V. Vaughan]

Ralf Wildenhues wrote:

Hi Gary,

* Gary V. Vaughan wrote on Thu, Nov 24, 2005 at 01:57:00PM CET:

Ralf Wildenhues wrote:

With response file support in GCC [1] we need to adjust Libtool
accordingly.  Minimally to let the option through as below, but
ideally we should probably parse its contents.

The spec says that the file must contain whitespace separated arguments,
so parsing should be a cinch.

Yes, but I believe the "recursinve include" semantics are not trivial;
but I don't remember the whole discussion and its resolution, I read
most of it at the time it was first discussed and have not reread it.

Is the patch necessary?

Yes.  Or a similar one, FWIW.

Won't @foo be treated as a file name and passed
through to the compiler driver by libtool anyway?

No.  You could `-Wc,@foo' of course, but..

Oh, okay.  Well committing this patch to 1.5 and HEAD seems prudent
in that case.

Or do you need to preserve relative argument order here?

 ..this would still be an issue.  This is of course not handled by my
simplistic patch.

Indeed.  But it is still an improvement over mishandling @foo entirely.

Any volunteers?  Comments?

After parsing we might want to change the arguments parsed from the file,
and presumably the file is used because the arguments are too long to pass
on the command line.  In that case, I suppose we might be able to cope
by using partial linking.

Or piecewise archiving, sure, *we* have all that machinery in place.

I'm worried about coping with a preponderance of non-object
arguments that overflow some tiny shell command line length limit...
but, I guess something like that will fool libtool regardless of
response files...  @foo support would give us a workaround though.

Since this is a gccism, and we'd like for libtool to present a portable
interface, I think that proper support for response files should be for
libtool to parse and interpret them, and rely on partial linking to help
us keep inside the command line length limits.

Erm.  We have -objectlist.  I have yet to see a different need for
response file semantics in libtool.

Too many -D/-I options... I'm sure there are others.

That way libtool users
get to use response files regardless of the underlying compiler.  In the
fullness of time, we might test for compiler response file support, and
have libtool write long command lines into its own response file instead
of using partial linking where possible.

This is what I was thinking of, too. :)

Not that we're likely to need it much with linker scripts, though.

Good call.  But it might make libtoolizing projects that use gcc and @foo
a tiny bit easier.

Regardless, this all sounds like post-2.0 to me...

Sure.  I just wanted to notify so we are aware.

can you add a TODO item please?

Oh, my previous mail was intended to be the TODO item, on your TODO
page, along with its URL when in the archive -- done now.  :)

Excellent.  Thankyou :-)

Cheers,
        Gary.
--
Gary V. Vaughan      ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature

_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool