Hi Carlo, * Carlo Contavalli wrote on Tue, Jan 17, 2006 at 07:04:55PM CET: > > With something like: > libtool --mode=link gcc -g -O2 -std=c99 -Wall -pedantic > -D_POSIX_C_SOURCE=200112L \ > -Wall -export-dynamic -module -avoid-version -rpath /test -o test.la > file.lo ../lib1/libtest.la ../lib2/libtest.la > > I get the error: > [...] > ar: .libs/test.lax/libtest.a/test1.o: No such file or directory > make[1]: *** [test.la] Error 1 > > The error is quite obvious from libtool output: > [...] > rm -fr .libs/test.lax/libtest.a > mkdir .libs/test.lax/libtest.a > (cd .libs/test.lax/libtest.a && ar x /test/lib1/.libs/libtest.a) > rm -fr .libs/test.lax/libtest.a > mkdir .libs/test.lax/libtest.a > (cd .libs/test.lax/libtest.a && ar x /test/lib2/.libs/libtest.a) > [...] > > As you can see, the directory libtest.a is first created. > There, lib1/libtest.a is extracted with ar x. Then, since lib2/libtest.a > has the same filename, the directory libtest.a is removed, > and recreated. The final result is that during link time > the file test1.o is missing.. (lib1/libtest.a contains test1.o, while > lib2/libtest.a contains test2.o).
Thanks for the concise bug report. Two comments: your libtest.la libraries are convenience archives, so this usage should probably be accepted. At least ATM I don't know of a system where we can't make it work. With general libraries, however, using the same name for two different libraries is simply not portable -- some systems don't have the means to even specify them correctly on the command line, some systems simply have a shared library system that does not allow two libs with the same soname to be loaded in core simultaneously. It should be a rather easy workaround to simply to rename one of the libraries; is there a reason this is may be unduly difficult in your situation? Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
