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
