Bob Friesenhahn <bfrie...@simple.dallas.tx.us> writes: > On Thu, 2 Jan 2020, wf...@niif.hu wrote: >> >>> In this case libtool is a slave of Automake and Automake is >>> controlling the build and installation order. This means that it >>> should be expected behavior. Installation is serialized and thus >>> order matters. >> >> But in case of a dependency cycle there's no correct order if libtool >> insists on using the installation directory for the -L option for >> relinking. And the installation directory may contain an incompatible >> version of the library anyway, just like it happens below. > > Indeed, sometimes it is necessary to re-organize libraries and code in > order to be successful given serialized linking.
I think libtool could support arbitrary shared library dependencies by using the -rpath-link option as necessary. >>>> and use it from liba, linking the final binary fails: >>>> >>>> $ make >>>> [...] >>>> /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o >>>> translib translib.o a/liba.la >>>> libtool: link: gcc -g -O2 -o .libs/translib translib.o a/.libs/liba.so >>>> -Wl,-rpath -Wl,/tmp/translib/lib >>>> /usr/bin/ld: a/.libs/liba.so: undefined reference to `b2' >>>> >>>> As I understand it, the -rpath linker option on the above command makes >>>> a/.libs/liba.so use the already installed (old) version of libb, which >>>> lacks the b2 symbol. What's the solution here? Why isn't that -rpath >>>> option "delayed" until the relinking phase? >>> >>> The -rpath linker option did not cause the library to be used. >> >> The above gcc linking command is successful if I omit the -rpath option. >> (The built-in RUNPATH of liba.so contains the build directory first. >> Just for the record: Debian's ld defaults to --enable-new-dtags.) > > I am not sure exactly what --enable-new-dtags means, but Ubuntu 18.04 > LTS's manual page says that this is not its default. This may > indicate changing behavior. I suspect it's just outdated documentation. What --enable-new-dtags does is adding DT_RUNPATH instead of DT_RPATH to ELF objects. See which one you find after building my example. >>> The '-r' in -rpath stands for 'run' and thus it is a path stored in a >>> built shared library or executable which tells it where to search for >>> other libraries when th program is executed. >> >> True, but man ld states in the -rpath-link option description that the >> directories specified by -rpath options are used with a very high >> priority for locating required shared libraries. > > This is interesting but I am not seeing any use of -rpath-link in > libtool. Neither do I, but I think it would be a possible way out of this situation. I wonder what the reason could be for libtool not using it. >>> I am not seeing 'libb' mentioned on the link line and that may be the >>> cause of the problem you are seeing. >> >> Sure enough, adding libb.la explicitly to the link command works around >> the issue, but since the binary does not use libb directly, it doesn't >> sound like a good solution to me, because it leads to overlinking. > > Libtool can only know what has been passed to it via the command line > and via the prior information it stored in the .la files (initially > found due to the command line). Yes, and liba indeed has the build directory libb.la in its dependency_libs, so the information is there and could be used with -rpath-link, unless I'm missing something important. > I have always found it to be good practice to include all dependency > libraries in an Automake 'LIBADD' statement so that all dependency > libraries are passed to libtool. But that causes overlinking, which is unpopular. And I'm not sure --as-needed could help here. > If the .la file passed to libtool mentions the dependencies, then > libtool is supposed to do the right thing. I think it does, see above. Libtool still fails to link the executable if an incompatible library is already installed (and you use a custom --prefix). > At this point I am wondering why I am the only person on this list who > has piped up with some sort of a response. :-( It's rather hard to get support for libtool, but I sorely need some, because this issue hurts a real software project. Since this is the first time I seriously deal with libtool, I certainly miss most of the picture, so I sincerely appreciate your "piping up". Let's hope others will join with time with their insights. -- Thanks, Feri