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