On Sat, Oct 07, 2006 at 03:41:53PM +0200, Carlo Wood wrote: > > 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).
You actually shouldn't use LIBS at all, and put all of them in _LDADD. And that also still works, but is all beside the point. > 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. I do not understand why -lz needs to be after libltdl.la. And I'm even more confused why you think -lx needs to be after -lz. libltdl.la does not want to use symbols from -lz, it want to use them from -ldl. It's just that -lz also happens to provide the same symbols. This does not put a requirement for -lz to be after libltdl.la. The only requirement that libltdl.la puts on you, is that if you use it as a convience/static library, that you follow it by an -ldl. The only reason I can see that you want to force libltdl.la in front of -lz is that you want it libltdl.la to use the dlopen() from -ldl, which you don't. You actually want it to use the one from -lz. And you can't actually even control which dlopen() it's going to use since you're using it as a convience/static library. Note that the linker does not record in which library it finds dlopen() (on ELF systems). If it's searching for a symbol, it just looks at the libraries that follow it, and if it finds it in one of them, it's happy. If either -lz or -ldl follow libltdl the linker will find it. This is unrelated to what the dynamic linker is doing to search the symbol, and this is were your problem is. The dynamic linker will always start from the first library in it's list to search a symbol. This is why you want -lz to be in front of any library that might be using (or providing) dlopen(), and why you should put it in front of libltdl.la. Even when the linker found dlopen() in -ldl, the dynamic linker will use the one from -lz because it's first in the list. The requirement you have is this case is that -lz comes for -ldl, but more in general, you want -lz to the the first library. I would also like to point out that in case you weren't using libltdl as a convience/static library (AC_LIBLTDL_INSTALLABLE instead of AC_LIBLTDL_CONVENIENCE), -lltdl -lz (without -ldl) should work too. Since -ldl is now still after -lz in the search order. It's not because it works that it's what you want, you still want the -lz before the -lltdl. This part is rather ELF specific. But I don't think you can do what you want to do in a portable way. > 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... I think this is the relavant change: - lt_module module = dlopen (filename, LT_GLOBAL | LT_LAZY_OR_NOW); + lt_module module = dlopen (filename, LT_LAZY_OR_NOW); Which is a backport from the head/2.0 branch. >From the dlopen() manpage: RTLD_GLOBAL The symbols defined by this library will be made available for symbol resolution of subsequently loaded libraries. This was removed because of bugs #195821 and #221811. Ralf, do you care to comment on this? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
