Re: LD_LIBRARY_PATH in wrapper scripts

On 2021-08-21 07:56, 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...

So, I've just looked through libtool source and the problematic
line is stamped out by the "libtool" script. So, here is a minimal
hack that addresses the immediate issue:

--- libtool 2021-08-21 09:16:55.317889207 -0700

+++ libtool.patched 2021-08-21 09:15:34.309736278 -0700

@@ -6083,7 +6083,9 @@

if test yes = "$shlibpath_overrides_runpath" && test
-n "$shlibpath_var" && test -n "$temp_rpath"; then

$ECHO "\

# Add our own library path to $shlibpath_var

- $shlibpath_var=\"$temp_rpath\$$shlibpath_var\"

+ $shlibpath_var=\".libs\"

# Some systems cannot cope with colon-terminated $shlibpath_var

# The second colon is a workaround for a bug in BeOS R4 sed

Is there a user-facing way to control this?

Thanks!

Oleg.