On Sat, Aug 21, 2021 at 4:25 PM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> 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
> >
> LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu:/home/oleg/project/_obj/.libs:/opt/gcc-11/lib/../lib64:$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:
$shlibpath_var=\"$temp_rpath\$$shlibpath_var\"
Thanks!
Oleg.
