Re: LD_LIBRARY_PATH set by wrapper on Ubuntu, not on Rocky (Redhat)

[Frederic Berat]

Hello,

> As for why RHEL behaves differently, I remember that RHEL patches libtool so 
> unless you installed from source you might take a look at whether you're 
> running a modified install.

The behavior is likely not due to patches on libtool (at least I
couldn't find anything obviously relevant), but more probably to the
default behavior of gnu ld.
>From the behavior described in the thread earlier, it looks like
Debian has the "--enable-dtags" option set to ld, while Redhat doesn't
have it. That leads to RUNPATH being set on Debian while RPATH is set
on REDHAT, which by side effect modifies the behavior of libtool, if I
get it right.

Interestingly, Vincent opened a bug report in Debian a few years ago
[1], complaining that "--enable-dtags" was breaking tests generated by
libtool. I wonder if there was any follow-up on this, and what was the
conclusion.

Fred.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732

On Mon, Sep 5, 2022 at 10:53 PM Alex Ameen <alex.ameen.tx@gmail.com> wrote:
>
> I've run into situations like this on RHEL 6 and 7 with libtool 2.4.6. My 
> approach was manually write a recipe to link a shlib looking in `.libs/' and 
> avoid the wrapper to be used at "build time".
>
> The wrapper is made redundant by `RUNPATH' in my opinion when used with 
> `$ORIGIN'; but your mileage may vary.
>
> As for why RHEL behaves differently, I remember that RHEL patches libtool so 
> unless you installed from source you might take a look at whether you're 
> running a modified install.
>
> On Sun, Sep 4, 2022, 3:20 PM Corey Minyard <minyard@acm.org> wrote:
>>
>> I have a library and tools that uses autotools for building.  It
>> generates some modules that get loaded at runtime by searching
>> LD_LIBRARY_PATH and then a libexec directory.
>>
>> On a current Ubuntu system (22.04.1, automake 1.16.5, autoconf 2.71,
>> libtool 2.4.6) and an older Ubuntu system (20.04.5, automake 1.16.1,
>> autoconf 2.69, libtool 2.4.6) the wrapper file for the program sets
>> LD_LIBRARY_PATH to the various lib directories:
>>
>>   if test -f "$progdir/$program"; then
>>     # Add our own library path to LD_LIBRARY_PATH
>>     
>> LD_LIBRARY_PATH="/personal/git/gensio/Z/lib/.libs:/personal/git/gensio/Z/glib/.libs:/personal/git/gensio/Z/tcl/.libs:$LD_LIBRARY_PATH"
>>
>> On a current Rocky linux system (9.0, automake 1.16.2, autoconf 2.69,
>> libtool 2.4.6) which should be equivalent to RHEL, it generates no such
>> code in the same place.  It doesn't set LD_LIBRARY_PATH at all, and I
>> guess uses rpath to find the libraries.  It's exactly the same code and
>> configuration on both systems.
>>
>> I haven't been able to figure out why looking at patches between the two
>> versions internet searches.  The Rocky behavior is breaking my program
>> when running from the wrapper because it's not finding the modules
>> because they are not installed.  It works fine on Ubuntu because
>> LD_LIBRARY_PATH is set.  And the libtool documentation states that
>> searching LD_LIBRARY_PATH for modules should work, under "10.4 Finding
>> the correct name to dlopen":
>>
>>      If your program uses this approach, then it should search the
>>   directories listed in the 'LD_LIBRARY_PATH'(1) environment variable, as
>>   well as the directory where libraries will eventually be installed.
>>   Searching this variable (or equivalent) will guarantee that your program
>>   can find its dlopened modules, even before installation, provided you
>>   have linked them using libtool.
>>
>> I haven't figured out why, and I can't find a way to force libtool to
>> put in the LD_LIBRARY_PATH.  What am I doing wrong?
>>
>> -corey
>>