Hello,

In GNU Texinfo we would like to use dlopened objects linked against
libraries.  It works out of the box (with libtool) for some platforms,
but not all.  We would like to be able to use this in-build for tests.

In most platforms, rpaths are used to make it work, with relinking when
installing.  However, this is not done for every platforms.  The
problematic platforms are OpenBSD and Macos when dlopened object and
libraries are in the same directory.  Cygwin (and minGW on Cygwin) also
fails when the dlopened object and libraries are not in the same
directory.

We do not necessarily have access to those platforms, but we have setup
(thanks to Bruno Haible) a minimal example in a CI on
https://github.com/gnu-texinfo/ci-scratch to show the issue.  The code
is in
https://github.com/gnu-texinfo/ci-scratch/tree/master/test-libraries-dir
prog.c is the main program, it dlopens lib1, which is linked against
library/lib2.c.

The result of the CI run is here:
https://github.com/gnu-texinfo/ci-scratch/actions/runs/17330769906
It is not possible to see the logs without an account, it requires
getting the uploaded logs, so here are the messages:

Macos:
.libs/lib1.0.so: dlopen error: dlopen(.libs/lib1.0.so, 0x0001): Library not 
loaded: /usr/local/lib/lib2.0.dylib
  Referenced from: <F7CA572D-516C-3638-9241-7403CAD65572> 
/Users/runner/work/ci-scratch/ci-scratch/test-libraries-fail/build/.libs/lib1.0.so
  Reason: tried: '/usr/local/lib/lib2.0.dylib' (no such file), 
'/System/Volumes/Preboot/Cryptexes/OS/usr/local/lib/lib2.0.dylib' (no such 
file), '/usr/local/lib/lib2.0.dylib' (no such file)

OpenBSD:
.libs/lib1.so.0.0: dlopen error: Cannot load specified object

Cygwin
.libs/cyg1-0.dll: dlopen error: No such file or directory
/cygdrive/d/a/ci-scratch/ci-scratch/test-libraries-dir/build/.libs/cyg1-0.dll: 
dlopen error: No such file or directory

I have no idea if this is actually related to libtool, but even if it is
not I would imagine that there is good expertise on this subject here.
Any idea on how to make that work?

If that works for in-build, we would also like to have it work for
installed libraries and dlopened objects, but this could be in a second
step.  It could also be challenging because we do not install the
libraries in the default paths because these are not supposed to be
public libraries.


As a side note, I had a look at (relatively) recent commits in libtool
related to OpenBSD, and it seems that there is something specific for
this platform, where rpath seem not to be used, instead ldconfig need to
be called to have libraries found.

This is what I understood by reading the description of the --no-finish
and --reorder-cache libtool options descriptions in  
https://www.gnu.org/software/libtool/manual/html_node/Invoking-libtool.html

But I have no idea on how to turn that in useful information, and it may
be irrelevant.


For more background, in GNU Texinfo, we often use Perl XS extensions,
which are dlopened objects that can be used to use native code
implemented in C from Perl.  We also have C libraries, which implement
the actual treatments, the XS objects being actually interfaces to the C
libraries.

We use two interfaces.  In the texi2any program, we have our own loader
of XS extensions, and to make it work, we associate extensions to the
list of the libraries they depend on, and we preload these libraries
after having located them by getting the dlname in the .la files.  In
that setup, we make it work on OpenBSD and Cygwin (on MacOS a
non-working iconv is detected, therefore XS extensions that are linked
against libraries are not used, so we do not know if it would work too).

There is also a SWIG interface, and we started testing and using the
Perl SWIG interface.  In that case, we do not control the loader, and
it fails for OpenBSD and Cygwin in the CI.


On the analysis of the issue for texi2any and the solution using preloading:
https://lists.gnu.org/archive/html/bug-texinfo/2024-11/msg00098.html
https://lists.gnu.org/archive/html/bug-texinfo/2024-11/msg00106.html

On the resurfacing issues with the SWIG interface:
https://lists.gnu.org/archive/html/bug-texinfo/2025-08/msg00033.html

-- 
Pat

Reply via email to