Bug#391427: Debian's version of libtool breaks correct link order
On Sat, Oct 07, 2006 at 01:56:21AM +0200, Carlo Wood wrote: For libcwd to work, you really want it to be the first library in the list, before any other, so even before libltdlc.la. This should make sure that the dynamic linker will use your functions. That is nonsense! When both libraries depend on third, then the third has to be specified last by libtool. libcwd is already linked to -ldl, and it doesn't need to be linked to it again. The only thing that has a dependency on -ldl that libtool should care about at this point is libltdlc.la. You want your -lcwd to be the first dynamic library that's linked against, so you should put it first on your command line. That libltdlc.la happens to be a static library in this case just made it work for you. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391427: Debian's version of libtool breaks correct link order
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.orig2006-10-07 08:38:24.0 + +++ Makefile.am 2006-10-07 08:38:34.0 + @@ -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. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391427: Debian's version of libtool breaks correct link order
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.orig2006-10-07 08:38:24.0 + +++ Makefile.am 2006-10-07 08:38:34.0 + @@ -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, quoteUnresolved 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]
Bug#391427: Debian's version of libtool breaks correct link order
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, quoteUnresolved 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]
Bug#391427: Debian's version of libtool breaks correct link order
Package: libtool Version: 1.5.22-4 After changing my OS from fedora core 5 to debian testing, one of my projects started to dump core. I tracked down the reason for it, and it turned out that during linking one library was suddenly put way more to the front (to the left). That this can be blamed to debian's libtool version has been verified by changing ONLY the 'libtool' file installed in the srcdir of the application: With debians libtool, I get: ~/projects/edragon/edragon-objdir/srcgrep '^VERSION' ../libtool VERSION=1.5.22 Debian 1.5.22-4 ~/projects/edragon/edragon-objdir/srcrm edragon ~/projects/edragon/edragon-objdir/srcmake Making all in include make[1]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src/include' make all-recursive make[2]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src/include' Making all in IniFile make[3]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src/include/IniFile' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src/include/IniFile' make[3]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src/include' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src/include' make[2]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src/include' make[1]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src/include' Making all in utils make[1]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src/utils' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src/utils' Making all in gui make[1]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src/gui' Making all in include make[2]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src/gui/include' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src/gui/include' make[2]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src/gui' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src/gui' make[1]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src/gui' Making all in . make[1]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src' /bin/sh ../libtool --tag=CXX --mode=link g++ -g -DCWDEBUG -I/usr/local/install/4.1.2-20060901/include -W -Wall -Wundef -DDEBUG -I/usr/include/boost-1_33_1 -export-dynamic -o edragon -export-dynamic -no-undefined -Wl,--whole-archive,utils/.libs/libutils.a,--no-whole-archive edragon-Application.o edragon-GUI_interface.o edragon-IniFile.o edragon-PathList.o edragon-PluginFile.o edragon-PluginsManager.o edragon-RCFile.o edragon-Runtime.o edragon-XMLFile.o edragon-testsuite_hooks.o ../libltdl/libltdlc.la -L/usr/local/install/4.1.2-20060901/lib -lcwd -lboost_filesystem-gcc-d-1_33_1 -L/usr/local/install/4.1.2-20060901/lib -lcairo -L/usr/local/install/4.1.2-20060901/lib -lglib-2.0 -L/usr/local/install/4.1.2-20060901/lib -lxmlwrapp -lxsltwrapp -lxslt -lxml2 -L/usr/local/install/4.1.2-20060901/lib -lcw g++ -g -DCWDEBUG -I/usr/local/install/4.1.2-20060901/include -W -Wall -Wundef -DDEBUG -I/usr/include/boost-1_33_1 -o edragon -Wl,--whole-archive -Wl,utils/.libs/libutils.a -Wl,--no-whole-archive edragon-Application.o edragon-GUI_interface.o edragon-IniFile.o edragon-PathList.o edragon-PluginFile.o edragon-PluginsManager.o edragon-RCFile.o edragon-Runtime.o edragon-XMLFile.o edragon-testsuite_hooks.o -Wl,--export-dynamic ../libltdl/.libs/libltdlc.a -ldl -L/usr/local/install/4.1.2-20060901/lib /usr/local/install/4.1.2-20060901/lib/libcwd.so -lboost_filesystem-gcc-d-1_33_1 /usr/local/install/4.1.2-20060901/lib/libcairo.so /usr/local/install/4.1.2-20060901/lib/libglib-2.0.so /usr/local/install/4.1.2-20060901/lib/libxmlwrapp.so /usr/local/install/4.1.2-20060901/lib/libxsltwrapp.so /usr/lib/libxslt.so /usr/lib/libxml2.so /usr/local/install/4.1.2-20060901/lib/libcw.so -Wl,--rpath -Wl,/usr/local/install/4.1.2-20060901/lib -Wl,--rpath -Wl,/usr/local/install/4.1.2-20060901/lib make[1]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src' Making all in plugins make[1]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src/plugins' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src/plugins' Making all in testsuite make[1]: Entering directory `/home/carlo/projects/edragon/edragon-objdir/src/testsuite' make[1]: Leaving directory `/home/carlo/projects/edragon/edragon-objdir/src/testsuite' The problem here is that -ldl appears before /usr/local/install/4.1.2-20060901/lib/libcwd.so Using the original libtool, this does not happen: ~/projects/edragon/edragon-objdir/srccp -p ../libtool.nondeb ../libtool
Bug#391427: Debian's version of libtool breaks correct link order
Oops. My previous comment was correct, but unrelated to the issue at hand, which I haven't been able to analyze yet. Can try to do next week (unless beaten to, of course ;-) Cheers, Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391427: Debian's version of libtool breaks correct link order
On Fri, Oct 06, 2006 at 04:03:42PM +0200, Carlo Wood wrote: The problem here is that -ldl appears before /usr/local/install/4.1.2-20060901/lib/libcwd.so Where does that -ldl come from? Does only libcwd need the -ldl, or does something else need -ldl too? What happens if the -ldl isn't on the command line at all? Can you show the output the objdump -p file |grep NEEDED for libcwd and the application? And the output from ldd file for the application? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391427: Debian's version of libtool breaks correct link order
On Fri, Oct 06, 2006 at 06:29:47PM +0200, Kurt Roeckx wrote: On Fri, Oct 06, 2006 at 04:03:42PM +0200, Carlo Wood wrote: The problem here is that -ldl appears before /usr/local/install/4.1.2-20060901/lib/libcwd.so Where does that -ldl come from? Does only libcwd need the -ldl, or does something else need -ldl too? What happens if the -ldl isn't on the command line at all? Can you show the output the objdump -p file |grep NEEDED for libcwd and the application? And the output from ldd file for the application? Does it reach your dlsym() call at all, or it's just using the one from libdl? I guess I got a little confused about your mail. If -ldl is first in the list, it should never reach your library in the first place. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391427: Debian's version of libtool breaks correct link order
Does it reach your dlsym() call at all, or it's just using the one from libdl? I guess I got a little confused about your mail. I think you didn't read it very well :p If -ldl is first in the list, it should never reach your library in the first place. I believe I said that in my first post, possible not too clear though: libcwd does not define dlsym. I don't understand why you think that no function of libcwd would ever be reached when there is a library before it in the list... What about it's _init function, to name one? -- Carlo Wood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391427: Debian's version of libtool breaks correct link order
On Fri, Oct 06, 2006 at 06:29:47PM +0200, Kurt Roeckx wrote: On Fri, Oct 06, 2006 at 04:03:42PM +0200, Carlo Wood wrote: The problem here is that -ldl appears before /usr/local/install/4.1.2-20060901/lib/libcwd.so Where does that -ldl come from? That is detailed explained in the my first post?? Repeat: ../libltdl/libltdlc.la pulls it in. The first post contains a full copy of this file. Does only libcwd need the -ldl, or does something else need -ldl too? See original post/above: ../libltdl/libltdlc.la What happens if the -ldl isn't on the command line at all? I gave the command line in my first post, there is no -ldl on the command line! :/ Repeat: /bin/sh ../libtool --tag=CXX --mode=link g++ -g -DCWDEBUG -I/usr/local/install/4.1.2-20060901/include -W -Wall -Wundef -DDEBUG -I/usr/include/boost-1_33_1 -export-dynamic -o edragon -export-dynamic -no-undefined -Wl,--whole-archive,utils/.libs/libutils.a,--no-whole-archive edragon-Application.o edragon-GUI_interface.o edragon-IniFile.o edragon-PathList.o edragon-PluginFile.o edragon-PluginsManager.o edragon-RCFile.o edragon-Runtime.o edragon-XMLFile.o edragon-testsuite_hooks.o ../libltdl/libltdlc.la -L/usr/local/install/4.1.2-20060901/lib -lcwd -lboost_filesystem-gcc-d-1_33_1 -L/usr/local/install/4.1.2-20060901/lib -lcairo -L/usr/local/install/4.1.2-20060901/lib -lglib-2.0 -L/usr/local/install/4.1.2-20060901/lib -lxmlwrapp -lxsltwrapp -lxslt -lxml2 -L/usr/local/install/4.1.2-20060901/lib -lcw (All of that is on one line). There is no -ldl there. Can you show the output the objdump -p file |grep NEEDED for libcwd and the application? And the output from ldd file for the application? I don't see how NEEDED is relevant here. The only thing that is relevant are the .la files involved (which were included in my first post). But ok here is the requested info: ~/projects/edragon/edragon-objdir-bugreport/srcldd edragon linux-gate.so.1 = (0xe000) libdl.so.2 = /lib/tls/libdl.so.2 (0xa7f68000) libcwd.so.0 = /usr/local/install/4.1.2-20060901/lib/libcwd.so.0 (0xa7eb4000) libboost_filesystem-gcc-d-1_33_1.so.1.33.1 = /usr/lib/libboost_filesystem-gcc-d-1_33_1.so.1.33.1 (0xa7e9f000) libcairo.so.2 = /usr/local/install/4.1.2-20060901/lib/libcairo.so.2 (0xa7e3f000) libglib-2.0.so.0 = /usr/local/install/4.1.2-20060901/lib/libglib-2.0.so.0 (0xa7dae000) libxmlwrapp.so.0 = /usr/local/install/4.1.2-20060901/lib/libxmlwrapp.so.0 (0xa7d8c000) libxsltwrapp.so.0 = /usr/local/install/4.1.2-20060901/lib/libxsltwrapp.so.0 (0xa7d83000) libxslt.so.1 = /usr/lib/libxslt.so.1 (0xa7d51000) libxml2.so.2 = /usr/lib/libxml2.so.2 (0xa7c38000) libcw.so.0 = /usr/local/install/4.1.2-20060901/lib/libcw.so.0 (0xa7be8000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xa7b09000) libm.so.6 = /lib/tls/libm.so.6 (0xa7ae4000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xa7ad8000) libc.so.6 = /lib/tls/libc.so.6 (0xa79a6000) /lib/ld-linux.so.2 (0xa7f7e000) libSM.so.6 = /usr/lib/libSM.so.6 (0xa799d000) libICE.so.6 = /usr/lib/libICE.so.6 (0xa7985000) libXrender.so.1 = /usr/lib/libXrender.so.1 (0xa797d000) libX11.so.6 = /usr/lib/libX11.so.6 (0xa78b6000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0xa7891000) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0xa7827000) libz.so.1 = /usr/lib/libz.so.1 (0xa7813000) libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0xa77e9000) libexslt.so.0 = /usr/lib/libexslt.so.0 (0xa77d8000) libXau.so.6 = /usr/lib/libXau.so.6 (0xa77d4000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0xa77cf000) libexpat.so.1 = /usr/lib/libexpat.so.1 (0xa77b) libgcrypt.so.11 = /usr/lib/libgcrypt.so.11 (0xa775f000) libgpg-error.so.0 = /usr/lib/libgpg-error.so.0 (0xa775b000) libnsl.so.1 = /lib/tls/libnsl.so.1 (0xa7744000) ~/projects/edragon/edragon-objdir-bugreport/srcobjdump -p /usr/local/install/4.1.2-20060901/lib/libcwd.so.0 | grep NEEDED NEEDED libdl.so.2 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libc.so.6 NEEDED libgcc_s.so.1 ~/projects/edragon/edragon-objdir-bugreport/srcobjdump -p ./edragon | grep NEEDED NEEDED libdl.so.2 NEEDED libcwd.so.0 NEEDED libboost_filesystem-gcc-d-1_33_1.so.1.33.1 NEEDED libcairo.so.2 NEEDED libglib-2.0.so.0 NEEDED libxmlwrapp.so.0 NEEDED libxsltwrapp.so.0 NEEDED libxslt.so.1 NEEDED libxml2.so.2 NEEDED libcw.so.0 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so.6 ~/projects/edragon/edragon-objdir-bugreport/src./edragon COREDUMP: libcwd:cwbfd::ST_init: dlsym(RTLD_NEXT, dlopen) returns NULL; please check that you didn't specify -ldl before (left of) -lcwd while linking. Obviously NEEDED libdl.so.2 appears
Bug#391427: Debian's version of libtool breaks correct link order
On Sat, Oct 07, 2006 at 12:38:15AM +0200, Carlo Wood wrote: Does it reach your dlsym() call at all, or it's just using the one from libdl? I guess I got a little confused about your mail. I think you didn't read it very well :p If -ldl is first in the list, it should never reach your library in the first place. I believe I said that in my first post, possible not too clear though: libcwd does not define dlsym. So, only dlopen() and dlclose(). I don't understand why you think that no function of libcwd would ever be reached when there is a library before it in the list... What about it's _init function, to name one? What I was trying to say there is that if you have a dlsym() (which you don't) it would never call your dlsym() since it already found the other first. Anyway, after reading your mails again, I see where the -ldl comes from now. You have ../libltdl/libltdlc.la before -lcwd in your call to libtool, and I think that is part of the problem. It expands libltdlc.la to libltdlc.a and -ldl, and there isn't any reorder there. At a later time you also say it to link to -ldl, which is a duplicate, and libtool removes it from the command line. For libcwd to work, you really want it to be the first library in the list, before any other, so even before libltdlc.la. This should make sure that the dynamic linker will use your functions. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391427: Debian's version of libtool breaks correct link order
On Sat, Oct 07, 2006 at 01:24:20AM +0200, Kurt Roeckx wrote: You have ../libltdl/libltdlc.la before -lcwd in your call to libtool, and I think that is part of the problem. It expands libltdlc.la to libltdlc.a and -ldl, and there isn't any reorder there. At a later time you also say it to link to -ldl, which is a duplicate, and libtool removes it from the command line. I DON'T say it to link to -ldl ! What I say is: libltdlc.a -lcwd BOTH depends on -ldl and therefore the generated g++ command should be: libltdlc.a -lcwd -ldl and NOT libltdlc.a -ldl -lcwd For libcwd to work, you really want it to be the first library in the list, before any other, so even before libltdlc.la. This should make sure that the dynamic linker will use your functions. That is nonsense! When both libraries depend on third, then the third has to be specified last by libtool. The upstream libtool does this correctly. Only your 'debian' version is broken in this regard. It is WRONG to outout -ldl this early. Your libtool is buggy. -- Carlo Wood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391427: Debian's version of libtool breaks correct link order
I wrote a test case, see attached tar ball. To run, execute: tar xzf bugreport391427.tar.gz cd bugreport391427 ./autoconf.sh make ./tst The reason that it does work seems to be that debian's libtool doesn't detect that '-lx' depends on -ldl. The ./tst succeeds when either: 1) -ldl is added to the libtool command (right of -lx) This cause libtool to delete the previous -ldl. Thus: having: ./libltdl/libltdlc.la -Linstall/lib -lx -ldl results in: libltdlc.a -ldl libx.so -ldl internally, which is then changed correctly to: libltdlc.a libx.so -ldl OR 2) It is even possible to let libtool detect that -lx depends on -ldl by editting the libtool file and changing: link_all_deplibs=no into link_all_deplibs=yes After doing 2), we get: /bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o tst tst.o ./libltdl/libltdlc.la -Linstall/lib -lx mkdir .libs gcc -g -O2 -o tst tst.o ./libltdl/.libs/libltdlc.a -L/home/carlo/src/debian/bugreport391427/install/lib /home/carlo/src/debian/bugreport391427/libx/../install/lib/libx.so -ldl -Wl,--rpath -Wl,/home/carlo/src/debian/bugreport391427/libx/../install/lib -Wl,--rpath -Wl,/home/carlo/src/debian/bugreport391427/libx/../install/lib Note how the libtool command line does NOT contain -ldl, and that -ldl appears AFTER libx.so. ~/src/debian/bugreport391427./tst Success! Also note, that this edit of libtool is not needed with the stock/upstream libtool. Attached: tst.tar.gz -- Carlo Wood [EMAIL PROTECTED] bugreport391427.tar.gz Description: Binary data
