On Sat, Oct 07, 2006 at 10:41:39AM +0200, Kurt Roeckx wrote: > On Sat, Oct 07, 2006 at 02:46:01AM +0200, Carlo Wood wrote: > > I wrote a test case, see attached tar ball. > > > > To run, execute: > > > > tar xzf bugreport391427.tar.gz > > cd bugreport391427 > > ./autoconf.sh > > make > > ./tst > > The following patch works for me: > --- Makefile.am.orig 2006-10-07 08:38:24.000000000 +0000 > +++ Makefile.am 2006-10-07 08:38:34.000000000 +0000 > @@ -2,9 +2,8 @@ > bin_PROGRAMS = tst > DEFS = -DHAVE_CONFIG_H > INCLUDES = $(LTDLINCL) > -LIBS = -Linstall/lib -lx > +LIBS = -Linstall/lib -lx $(LIBLTDL) > tst_SOURCES = tst.c > -tst_LDADD = $(LIBLTDL) > > # Fix broken clean up targets of autotools: > > > As I said, you want -lx before libltdl on the command line for > libtool/gcc, and you can't expect things to work if they don't.
It has worked fine for years (with the upstream libtool), so don't say "it can't work". It STILL works with the upstream libtool, only after applying the debian specific patches to libtool, libtool stops seeing that libx depends on libdl. Your "solution" is a workaround that only works for the testcase. In general, you cann't move a convenience library just like that to LIBS anyway (there is a good reason that I added it to _LDADD in the first place). But ok, lets consider the following case, which demonstrates another reason why your workaround can't always be used: Suppose you have, - library x that depends on dl (with it's own maintainer) - library ltdl that depends on dl (another maintainer) - library z that redefines dlopen, so it has to be put right-of library ltdl; however - you need it to be left-of library x, because you need library x to see the real dlopen that it expects (perhaps 'dlopen' is not a good example - but the names aren't that important). - An application that uses libraries x, ltdl and z. With the stock libtool, you'd do (although I'd add the .la to _LDADD, but ok - it needs to be first anyway now): LIBS = libltdl.la -lz -lx Reason for the order: -lz must be right-of libltdl and left-of -lx, dictating this precise order. Stock libtool will see that both libltdl.la and -lx need to be linked against -ldl, and therefore put -ldl on the right of all of this; this is THE solution, since obviously libdl doesn't depend on any of the other libraries. The g++ command line will contain, libltdl.a -lz -lx -dl Debian's libtool produces: libltdl.a -dl -lz -lx which is broken as we saw before. Your solution to change LIBS to: LIBS = -lx libltdl.la -lz just to artificially get a '-ldl' right-of -lx clearly won't work anymore in this case, proving that it was a kludge -- not the solution. I can't make this anymore clear, besides I don't have more time for this either; I've run into another debian-related problem that demands my attention (remember I recently switched to debian for the first time in 20 years that I use linux -- this reveals a few things that newbie users who start to work with linux/debian right away won't notice, much less write bug reports about). It seems we are getting nowhere here anyway, so I'll use some kludgy workaround to get things to work, especially for debian :( I might sent you another email by the way, because it turns out that libltdl is broken too, or so it seems. With the stock libtool version I can load a "plugin" that defines a function f1, and then load another plugin that calls this function. According to http://www.delorie.com/gnu/docs/libtool/libtool_46.html this is the expected behaviour. It says, <quote>Unresolved symbols in the module are resolved using [its dependency libraries (not implemented yet) and] previously dlopened modules.</quote> (the '[' and ']' are mine). So, when this suddenly stops working when the only thing that I change is moving from fedora core 5 to debian testing, then I thing something else is coming your way :/ But I need more time to investigate the exact reason first... Regards, Carlo Wood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
