On Mon, Aug 25, 2025 at 04:30:54PM +0200, Patrice Dumas wrote: > I think that this is the same issue that was discussed some months ago > for the XS modules used internally by texi2any, the loader does not find > the libraries since they are not in the locations it looks for and there > is no rpath or similar either: > https://lists.gnu.org/archive/html/bug-texinfo/2024-11/msg00098.html > > At that time, Gavin found a solution, by modifying our XS loading code > such that the libraries the XS extension depends on are pre-loaded: > https://lists.gnu.org/archive/html/bug-texinfo/2024-11/msg00106.html
I have put together some minimal test cases to show the problem. Perhaps
you could test them and confirm that the problem occurs, before reporting
to the libtool developers?
(Attachments renamed because otherwise they are blocked by my email provider.)
First is the source files in test-library-ok.tar.gz. To build this,
you need to change the file name of SHARED_LIB in prog.c to the file
name that is used on a system (for example, ".libs/lib1.so.0.0.0" might
become ".libs/lib1.so.0.0").
This runs fine on GNU/Linux (Linux Mint 21.2 Victoria) and the OpenBSD
system where I tested it (OpenBSD 7.7), when after generating the
build system ("autoreconf -vi", followed by configure and make), running
"./prog" manages to load the shared library "lib1" and run the function
inside it to print a message ("inside foo").
test-library-fail.tar.gz shows the problem with an extra layer of libraries.
prog loads lib1, which depends on lib2. This works on GNU/Linux, but not
OpenBSD. On GNU/Linux, RUNPATH is recorded in lib1:
$ readelf -a .libs/lib1.so.0.0.0 | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath:
[/home/g/src/texinfo/libtool-test-case/.libs]
There is no such record on OpenBSD in .libs/lib1.so.0.0. There the
dlopen call to load lib1 fails with the error "Cannot load specified object".
test-libraries-fail.targz
Description: Binary data
test-libraries-ok.targz
Description: Binary data
