On Tue, Nov 19, 2024 at 09:04:19PM +0000, Gavin Smith wrote: > Dynamic section at offset 0x390 contains 27 entries: > Tag Type Name/Value > 0x0000000000000001 (NEEDED) Shared library: [libtexinfoxs.so.0.0] > 0x0000000000000001 (NEEDED) Shared library: [libtexinfo.so.0.0] > 0x0000000000000001 (NEEDED) Shared library: [libintl.so.8.0] > 0x0000000000000001 (NEEDED) Shared library: [libunistring.so.0.1] > 0x0000000000000001 (NEEDED) Shared library: [libiconv.so.7.1] > 0x000000000000000f (RPATH) Library rpath: > [/usr/libdata/perl5/mips64-openbsd/CORE] > 0x000000000000001d (RUNPATH) Library runpath: > [/usr/libdata/perl5/mips64-openbsd/CORE] > > There is no mention of any .libs directory anywhere.
Indeed, and because of that I can't see how it could work to find the libraries in the build. > I thought I would try with "make install" to see what libtool did with > the .so files: > Then the lines in the output of readelf are the same: > > Dynamic section at offset 0x390 contains 27 entries: > Tag Type Name/Value > 0x0000000000000001 (NEEDED) Shared library: [libtexinfoxs.so.0.0] > 0x0000000000000001 (NEEDED) Shared library: [libtexinfo.so.0.0] > 0x0000000000000001 (NEEDED) Shared library: [libintl.so.8.0] > 0x0000000000000001 (NEEDED) Shared library: [libunistring.so.0.1] > 0x0000000000000001 (NEEDED) Shared library: [libiconv.so.7.1] > 0x000000000000000f (RPATH) Library rpath: > [/usr/libdata/perl5/mips64-openbsd/CORE] > 0x000000000000001d (RUNPATH) Library runpath: > [/usr/libdata/perl5/mips64-openbsd/CORE] > > No mention of any "/usr/local/lib/texi2any" directory. Did you try launching texi2any with TEXINFO_XS=debug? Since there is no RUNPATH/RPATH to /usr/local/lib/texi2any I would assume that the XS modules could not be loaded. > I expect that @dl_library_path in the Perl DynaLoader module could easily be > irrelevant for dependencies of libraries it loads, as this is only used > to find the library itself, not the library dependencies. I tried to add to @DynaLoader::dl_resolve_using the libtexinfo and libtexinfoxs libraries files, but it does not seems to work on GNU/Linux, so I do not think it will work better on any other platform. I test with ./configure and "make install DESTDIR=/home/dumas/tmp/dest/". I go to /home/dumas/tmp/dest/usr/bin. In that case, the runpath in ../lib/texi2any/Parsetexi.so is, as expected, set to the installation directory known by configure: 0x000000000000001d (RUNPATH) Library runpath: [/usr/local/lib/texi2any] In /home/dumas/tmp/dest/usr/bin, I run, with TEXINFO_XS set to debug: ./texi2any --html ~/src/texinfo/tp/t/input_files/simplest.texi -o - 2>&1 I get: checking ../lib/texi2any/Parsetexi.la found ../lib/texi2any/Parsetexi.la additional libraries: -ltexinfoxs|-ltexinfo found additional: ../lib/texi2any/libtexinfoxs.so|../lib/texi2any/libtexinfo.so Parsetexi: couldn't load file ../lib/texi2any/Parsetexi.so: libtexinfoxs.so.0: cannot open shared object file: No such file or directory at ../share/texi2any/Texinfo/XSLoader.pm That means that ../lib/texi2any/libtexinfo.so (which is a link to libtexinfoxs.so.0) was added to @DynaLoader::dl_resolve_using, but it did not help to find libtexinfoxs.so.0, presumably libtexinfoxs.so.0 is only searched for in /usr/local/lib/texi2any when loaded by dlopen. To me, that means that it is the dlopen or similar system that must find the libraries, we cannot use @DynaLoader::dl_resolve_using to supply other libraries. Then it means that for XS code that requires libtexinfo/libtexinfoxs, we need libtool to manage to setup things such that libtexinfo/libtexinfoxs are found by simply dlopen'ing Parsetexi.so and other similar XS objects, be it for in build testing or after installation in a directly when libraries are not searched for in the default case. So, I'd say that we cannot do anything else than filling bugs with libtool. And also that we should not wait for those issues to be fixed for the release. > > There is one thing that looks strange, a ^@ appears right after the > > texi2any error message for all the cases that fail to load, including > > macos. > > That's a null byte. Off-by-one error in the number of bytes to print? It comes from DynaLoader::dl_error(). Not a problem, actually. -- Pat
