[Top][All Lists]

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

Re: LD_LIBRARY_PATH in wrapper scripts

From: Bob Friesenhahn
Subject: Re: LD_LIBRARY_PATH in wrapper scripts
Date: Sat, 21 Aug 2021 18:24:58 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

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 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 '' 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.

Note that the compiler's run-time libraries are installed under /usr/lib/x86_64-linux-gnu (e.g. /usr/lib/x86_64-linux-gnu/

The wrapper scripts are used for running programs in the build tree. They are not meant to be installed.

Bob Friesenhahn,
GraphicsMagick Maintainer,
Public Key,

reply via email to

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