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

[Alex Ameen]

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