[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LD_LIBRARY_PATH in wrapper scripts

From: Oleg Smolsky
Subject: Re: LD_LIBRARY_PATH in wrapper scripts
Date: Sat, 21 Aug 2021 09:24:10 -0700
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]