Sirs:

I found a possible problem with Debian Stretch which I would like to
report (AMD64). At least it is behaving completely different from Debian Jessie. I am not sure which package it is related to. I googled some
texts about rpath, but no one seems to cover the problem I ran into.
Here it goes:

I wrote an application in C which loads some dynamic libraries
automatically at start up. The application can also make use of dlopen
while it is running to load additional shared objects.

All shared objects created along with the application are stored in the
same directory where the main binary code is. The linker uses
rpath='$ORIGIN' and everything works fine under Jessie, but it does not
work under Stretch.

I found that the problem happens when dlopen tries to open a shared
object which depends on an additional shared object which is at the same application directory. The application cannot find it. As an example,
let's say that in a directory bin1 there are 4 files, namely a.bin,
b.so, c.so and d.so. a.bin depends on b.so and load it without problems
during load time. After the a.bin starts, when dlopen tries to load
c.so, it is able to find it, but because c.so depends on d.so (which is
not loaded) dlopen of c.so fails. The dlopen failure message says dlopen
was not able to find d.so, which is there at the same directory as c.so,
which was found.

The main difference between a.bin in the two flavors of Linux in that on Jessie, rpath='$ORIGIN' will set RPATH in the elf file, while on
Stretch, it will set RUNPATH.

One way of solving the problem on Stretch is to add LD_LIBRARY_PATH=.
before the executable while calling it. The other is to link without the
the rpath option and then use patchelf to set RPATH (and not RUNPATH).
Since I do not want to use a script to call the application, I am using patchelf, but it seems strange that rpath='$ORIGIN' (at link time)
behaves differently between both flavors of Debian.

Thanks,

Alberto Sentieri

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)