Re: transitive shared library dependencies and installation
On Sun, 5 Jan 2020, wf...@niif.hu wrote: On the other hand, this overlinks the final binary: $ objdump -p .libs/translib | fgrep NEEDED NEEDED liba.so NEEDED libb.so NEEDED libc.so.6 libb.so is unneeded here (but is present in the installed program as well). Coincidentally, the most prominent search result https://wiki.mageia.org/en/Overlinking_issues_in_packaging mentions that "this is fixed using a patch from Debian" for libtool. What's your position on this? Is overlinking a problem or not? (It causes problems for distributions.) Should everybody use --as-needed globally to combat it? Something else entirely? This has been the most common complaint (in the GNU Linux world) I have heard about libtool. There is a choice of working reliably and portably (with possible over-linking) or relying on implicit library dependencies (which are definitely not portable), or failing as you have encountered. A similar complaint is that libtool uses information in installed ".la" files in order to link with all libraries that the program/library is dependent on. Due to this, GNU Linux distributions often patch out this capability, and they don't distribute ".la" files. Unfortunately, --as-needed may not be 100% reliable since it only reliably detects direct dependence on library symbols, and not "transitive" dependence. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: transitive shared library dependencies and installation
Roumen Petrov writes: > wf...@niif.hu wrote: > >>> So the right question is did reporter test with FSF version? >> >> I'm the reporter, and I didn't test any other version, as I wasn't >> even sure whether my example was correct and was supposed to work. > > You sample is correct . One minor nit is AM_PROG_AR - it is not > required for posted example. If you project requires use of this macro > you should request automake 1.11.2 as minimum. Hi Roumen, Thanks for the confirmation. Initially I didn't include AM_PROG_AR in the sample, but then autoreconf emitted much noise like /usr/share/automake-1.16/am/ltlibrary.am: warning: 'a/liba.la': linking libtool libraries using a non-POSIX /usr/share/automake-1.16/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac' Makefile.am:4: while processing Libtool library 'a/liba.la' (and the same for libb), and eventually I gave in. > Result on posted test case - pass: > $ ./translib ; echo $? > 12 Thanks for posting your results. Meanwhile I also tested with FSF libtool 2.4.6, and the final "make" indeed succeeds with it, unlike with Debian's libtool. The decisive difference is that with the FSF version the full build path to libb.so is explicitly added to the final link command, thus the linker needn't search for it by itself. On the other hand, this overlinks the final binary: $ objdump -p .libs/translib | fgrep NEEDED NEEDED liba.so NEEDED libb.so NEEDED libc.so.6 libb.so is unneeded here (but is present in the installed program as well). Coincidentally, the most prominent search result https://wiki.mageia.org/en/Overlinking_issues_in_packaging mentions that "this is fixed using a patch from Debian" for libtool. What's your position on this? Is overlinking a problem or not? (It causes problems for distributions.) Should everybody use --as-needed globally to combat it? Something else entirely? -- Thanks, Feri
Re: transitive shared library dependencies and installation
Hi Feri, wf...@niif.hu wrote: [SNIP] It is long history It starts with 1* (1.5) libtool . Libtool 1.5 has some issues with multiple dependent libraries (more then two). From debian was proposed a patch related to library dependencies. Unfortunately patch break existing regression test. From debian never was proposed version that pass regression test. Libtool 2.0 fixes his issues related to multiple libraries. On the same Debian did not stop to contribute patch that breaks libtool. As result when I decide to build something from source always to updated sources to FSF version. So the right question is did reporter test with FSF version? I'm the reporter, and I didn't test any other version, as I wasn't even sure whether my example was correct and was supposed to work. You sample is correct . One minor nit is AM_PROG_AR - it is not required for posted example. If you project requires use of this macro you should request automake 1.11.2 as minimum. Could you please provide some keywords to search for so that I can dig up the details of the above story? Please check libtool achives. To me situation on Debian is closed case. At the moment Debian carries 21 patches for libtool, if I could show that one of them breaks a valid use case, that would constitute a strong reason for dropping it. In moment I do tests on some sources from development or stable branches on an another system (archaic :) ): $ cat /etc/centos-release CentOS release 6.10 (Final) $ autoconf --version autoconf (GNU Autoconf) 2.63 $ automake --version automake (GNU automake) 1.11.1 $ libtool --version ltmain.sh (GNU libtool) 2.2.6b All is based on system packages except tested by me. Result on posted test case - pass: $ ./translib ; echo $? 12 $ readelf -a a/.libs/liba.so | grep RPATH 0x000f (RPATH) Library rpath: [/home/centos/.builds/test/autotools/translib/b/.libs:/tmp/translib/lib] $ readelf -a .libs/lt-translib | grep PATH 0x000f (RPATH) Library rpath: [/home/centos/.builds/test/autotools/translib/a/.libs:/home/centos/.builds/test/autotools/translib/b/.libs:/tmp/translib/lib] $ readelf -a .libs/translib | grep PATH 0x000f (RPATH) Library rpath: [/tmp/translib/lib] $ readelf -a /tmp/translib/lib/liba.so | grep PATH 0x000f (RPATH) Library rpath: [/tmp/translib/lib] Regards, Roumen Petrov
