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      ())_.  address@hidden,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