libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extract the archive name from the .la file and use $AR (not ar).


From: Peter Rosin
Subject: Re: Extract the archive name from the .la file and use $AR (not ar).
Date: Tue, 31 Aug 2010 19:21:34 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

Den 2010-08-31 19:11 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Tue, Aug 31, 2010 at 07:09:30PM CEST:
>> Den 2010-08-31 19:04 skrev Ralf Wildenhues:
>>> * Peter Rosin wrote on Tue, Aug 31, 2010 at 11:49:18AM CEST:
>>>> Pushing as attached, expected fail on Cygwin/ar and unexpected pass on
>>>> MSYS/lib just as before.
>>>
>>> Why does it pass with MSYS/lib?  Does lib expand the individual objects
>>> of the passed library-to-add?  If no, then can we make the test stricter
>>> so that it correctly fails here as well?
>>
>> I don't think there's a way to store an archive in an archive using lib.
>> It will just take the contents of the archive and put that in the new
>> archive instead, doing exactly what seems to be desired by the test.
> 
> Naa.  The test is just exposing a long-term bug in libtool itself:
> 
>   libtool --mode=link $CC ... -o libfoo.a baz.o libbar.a
> 
> should be adding baz.o and all objects in libbar.a to libfoo.a, i.e., it
> should extract all objects from libbar.a Instead, libfoo.a is added *as
> single member* into libfoo.a.  That's the bug.

(assuming typo and that you meant that libbar.a is added *as single member*)

In that case, MS lib does probably not see baz.o when it creates libfoo.a,
and the test could be made stricter by checking that baz.o is also part of
libfoo.a, since MS lib does the part that is currently tested for
(extracting libbar.a and putting the contents in libfoo.a).

Cheers,
Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]