[Top][All Lists]
[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.
- libtool 1.5.2 .libs/libfoo.a versus ar cru,
Kevin Ryde <=