bug-libtool
[Top][All Lists]
Advanced

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

libtool 1.5.2 .libs/libfoo.a versus ar cru


From: Kevin Ryde
Subject: libtool 1.5.2 .libs/libfoo.a versus ar cru
Date: Thu, 11 Mar 2004 09:17:13 +1000
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux)

In libtool 1.5.2 on a recent i386 debian, when libtool is asked to
link (--mode=link) a library, it doesn't remove the previous .a
library (eg. .libs/libfoo.a) before running "ar cru".

This can be seen for instance in the cdemo in the libtool dist,

        /bin/bash ./libtool --mode=link gcc  -g -O2   -o libfoo.la  
-no-undefined foo.lo -lm

        ar cru .libs/libfoo.a .libs/foo.o
        ranlib .libs/libfoo.a
        creating libfoo.la
        (cd .libs && rm -f libfoo.la && ln -s ../libfoo.la libfoo.la)

This is very bad during development, when a previous .libs/libfoo.a
exists, for two reasons.

Firstly if you change the object files going into the library, then
the old ones don't get removed from .libs/libfoo.a.

Secondly if two object files have the same name, in different
directories (eg. x/foo.lo, y/foo.lo), then the way GNU ar works is to
end up with just the second in the .a, if that .a already contains an
object file of that name (foo.o).

This is a regression from 1.5.0, where I believe care was taken to rm
the .a before running ar.


For what it's worth, I noticed this attempting to upgrade GMP to
libtool 1.5.2.  It has files of the same name in different directories
(eg. mpz/set_f.lo and mpq/set_f.lo) and gets bitten by the second case
above.




reply via email to

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