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

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Tue, Aug 24, 2010 at 11:48:50AM CEST:
> 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).

Correct.

> The old ar fallback is simply adding objects to the archive in batches
> when the command line gets longish...

Right.

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

Great!

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

Yes, it was this change I referred to, but no, there do not seem to be
problems with the patch.  It doesn't need reversal.  In fact, the @file
mechanism gets used with newish binutils on GNU/Linux as well and I'm
happy with that.  :-)

(For reference, the situation I was thinking of was newly-built ar
in a combined GCC+src/binutils build, possibly including cross
compilation.)

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

Hmm.  I wasn't aware that it was that which caused it to regress.

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

Right.

At this point, I think it's best to defer to Chuck's and your good
judgement on what you consider better for w32.  If Chuck's pending
patches are planned before the release, then hey, let's go forward
with them if you agree.

Thanks,
Ralf