|
From: | Christoph Egger |
Subject: | Re: darwin: mix up of .dylib and .bundle |
Date: | Sat, 15 Oct 2005 19:22:03 +0200 (MEST) |
> Christoph Egger wrote: > | Hi! > | > | libtool mixes up .dylib and .bundle. It thinks, > | .dylib are modules and .bundle are shared libs. > > Not here it doesn't... > > | > | This causes linking failures on darwin due to multiple defined symbols, > | in cases where libfoo.dylib is inherited from libbar.dylib > | and the program foo links against libbar.dylib and libfoo.dylib. > | libtool also prints a warning, "libfoo.dylib is a module, not a shared > | library", which is wrong. After digging deeper, I think this theory is wrong. This issue is a pretty nasty one. It is not easy to reproduce... See below for the details. > | I've attached a patch against cvs head which fixes this (for me at > | least). If the patch is not correct, then please give me one to test. > | > > I think I've seen this issue with the GNU libtool that Apple shipped (is > shipping?), You mean /usr/bin/libtool ? This is a binary used by gcc. > what version of glibtool are you using? Where did it originate? libtool cvs head > What version of darwin? MacOSX 10.4.2 > Or maybe it is just the fact that if there is no .dylib it > does its best and uses the .a? Please show steps to reproduce > too. I've created a small lib with the exact same buildsystem the original one use. So this small lib (I called it libtest) uses automake, autoconf and libtool the exact same way. See attachment: libtest.tar.gz autoconf 2.59 and automake 1.9.6 are required. If you use autoconf cvs and/or automake cvs than pass the option '--force' to step 2 How to use: 1. extract && cd libtest 2. ./autogen.sh 3. ./configure 4. make 5. make install Now the nasty thing: The original lib has a default development tree and a experimental tree. The difference is only (really only) in the source - NO diff in the buildsystem. I triple-checked to be sure. The default tree builds w/o any errors. The experimental tree runs into an linking error. The libtest builds w/o any errors. I attached the output of the same _sub_-directory of all three trees where the experimental one fails. 1) libgii-default.output is the output from the default tree. 2) libgii-experimental.output is the output from the experimental tree. 3) libtest.output is the output from libtest. Nonetheless, there are three different results: 1) shows how things should be. 2) libtool somehow tries to link in both shared and static versions into the same lib resulting into multiple definitions. 3) libtool see's the -rpath option twice... P.S.: How about integrating libtest into libtool's testsuite? It might uncover bugs on many other operating systems (win32, linux, *bsd, solaris, aix, etc.) -- Greetings, Christoph Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
libtest.tar.gz
Description: Unix tar archive
libgii-default.output
Description: Binary data
libgii-experimental.output
Description: Binary data
libtest.output
Description: Binary data
[Prev in Thread] | Current Thread | [Next in Thread] |