Re: [PATCH] Allow the use of a listing file if the archiver supports it.

[Peter Rosin]

Den 2010-08-13 13:17 skrev Peter Rosin:
> Den 2010-08-12 19:49 skrev Ralf Wildenhues:
>> Hi Peter,
>>
>> * Peter Rosin wrote on Thu, Aug 12, 2010 at 03:28:57PM CEST:
>>> This is a patch that makes use of @FILE support in the
>>> archiver, if the archiver supports it. That makes linking
>>> succeed for long command lines when using MSVC, as MSVC
>>> can't do piecewise linking (-r -o) which is the current
>>> fallback. Absolute paths still needs work, but that will
>>> have to wait for Chucks work in that area.
>>
>> Absolute paths are not a show stopper, for practical purposes.
>>
>> This is ok for master with nits below addressed.
> 
> Thanks for the review!
*snip*
> I have pushed as attached.
*snip*

Hmmm, your cross-post on bug-libtool@ and gcc@ made me look
one more time at this, and I realized that I have previously
completely misunderstood the failure. There isn't any piecewise
linking ($CC -r -o) going on in the other fallback code branch
(as is the case for the fallback for the name lister). The old
ar fallback is simply adding objects to the archive in batches
when the command line gets longish...

Thanks to the ar-lib script, it's no longer a special action
to add members to an archive using Microsoft lib, i.e. the old
fallback *should* work (I haven't tested for real, but I have
tested that ar-lib can add objects to an existing archive). So
in case there are GCC problems with this patch (it was this
change you referred to in that post, right?), it's perfectly
fine with me to revert it.

An added benefit of reverting would be that absolute file names
starts working for MSYS again (both MinGW and MSVC) without
Chuck's pending patches.

Another benefit of reverting is that if the objects are passed
on the command line, libtool isn't forced to convert absolute
file names it adds to the @file (on MSYS, still needed for
Cygwin), and we have learned that that can make some speed
difference...

On the other hand, the patch should be a (minor) speed
improvement in the normal case of relative file names.

Cheers,
Peter