On Sat, 21 Aug 2021, Oleg Smolsky wrote:
> Hello there! We have an autotools-based build system setup with a custom GCC where we take all build- and run-time dependencies (except for glibc)
> from /opt. Things have worked well on Ubuntu 16, yet I'm hitting a funky issue when building on Ubuntu20 (libtool 2.4.6-14 according to dpkg). The
> issue comes down to one of the wrapper scripts that contains this gem:
> # Add our own library path to LD_LIBRARY_PATH
> Most of our libs are statically linked with exception of just one. So tests/apps that use that shared lib end up with libtool wrappers... and they
> work correctly on Ubuntu16 (libtool 2.4.6-0.1 according to dpkg). It seems that libtool version just does not stamp out this extra variable...
> The manual fix is to remove the "/usr/lib/x86_64-linux-gnu" bit from the LD_LIBRARY_PATH above... and yet I have no idea where it came from or
> whether there is a way to influence its composition from a Makefile.am file.
I think that libtool tries to deduce the default run-time linker
search path (e.g. as used/provided to ldconfig, and also documented in
the 'ld.so' manual page) and it also tries to learn where the
compiler's own libraries are installed.
So, if libtool does not believe that /usr/lib/x86_64-linux-gnu is in
the default search path, it adds it.
Right, and my compiler is in /opt/gcc-11/ and so that addition to LD_LIBRARY_PATH is wrong. The system's compiler is older than what we use and the forced (older )version of libstdc++ breaks the executable.
So far the cleanest hack I've found is to patch the generated "libtool" script so that the generated test wrappers are correct. I do it that in the following crude way:
AC_CONFIG_COMMANDS([libtool-test-wrapper-fix], [sed -Ei ......... libtool])
That's obviously both nasty and fragile. Is there a better way to influence the composition of LD_LIBRARY_FLAGS? It comes from this: