On Wed, Nov 20, 2024 at 11:00:32AM +0100, Patrice Dumas wrote:
> 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.
> ...
> > 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.
Yes, but only for the uninstalled version. On the system I'm using,
I don't have permission to install under /usr/local (and I can't change
the --prefix because the iconv libraries that are needed for most of
the XS modules are installed under /usr/local). The XS modules without
library dependencies load successfully:
checking ../../tp/maintain/lib/Text-Unidecode/lib/MiscXS.la
checking ../../tp/maintain/lib/Unicode-EastAsianWidth/lib/MiscXS.la
checking ../../tp/maintain/lib/libintl-perl/lib/MiscXS.la
checking ../tp/Texinfo/XS/MiscXS.la
found ../tp/Texinfo/XS/MiscXS.la
../tp/Texinfo/XS/.libs/MiscXS.so loaded
looking for boot_Texinfo__MiscXS
trying to call boot_Texinfo__MiscXS...
...succeeded
- and later:
checking ../../tp/maintain/lib/Text-Unidecode/lib/XSParagraph.la
checking ../../tp/maintain/lib/Unicode-EastAsianWidth/lib/XSParagraph.la
checking ../../tp/maintain/lib/libintl-perl/lib/XSParagraph.la
checking ../tp/Texinfo/XS/XSParagraph.la
found ../tp/Texinfo/XS/XSParagraph.la
../tp/Texinfo/XS/.libs/XSParagraph.so loaded
looking for boot_Texinfo__Convert__Paragraph
trying to call boot_Texinfo__Convert__Paragraph...
...succeeded
attempting to override Texinfo::Convert::Plaintext::_process_text_internal with
Texinfo::MiscXS::process_text...
...succeeded
The other modules fail.
However, I got them to work by setting LD_LIBRARY_PATH. This is an
out-of-source build:
export top_srcdir=../../ top_builddir=.. TEXINFO_DEV_SOURCE=1
LD_LIBRARY_PATH=Texinfo/XS/.libs TEXINFO_XS=debug ./texi2any
../../doc/info-stnd.texi
All the modules load successfully then.
Setting $ENV{LD_LIBRARY_PATH} inside texi2any doesn't work, though (as
confirmed by this perlmonks post from 2001:
https://www.perlmonks.org/?node_id=126587). There are various hacks and
workarounds to get it to work; the question is how easy it would be
to do and would it be worth it.
Here's what appears to be the relevant documentation from "man ld.so":
ld.so searches for shared objects in the following lists of paths:
1. LD_LIBRARY_PATH environment variable if set
2. DT_RUNPATH of the calling object if set, otherwise:
1. DT_RPATH of the calling object if set
2. DT_RPATH of the program if set
(The use of DT_RPATH is deprecated as its behaviour varies
across operating systems.)
3. default search path set by ldconfig(8)
4. /usr/lib
I'm not completely sure what the "calling object" is in the case of
library dependencies of an XS module: whether it is the Perl executable
itself, or the XS module library file. It's possible that DynaLoader
doesn't, or can't, control any of this.
It's possible this problem wouldn't arise for an uninstalled program binary
linking against uninstalled Libtool libraries, as DT_RUNPATH would be
set in the program binary (I haven't checked, though). This could be
a more common case than what we are doing with texi2any.
Also, providing an extra flag when compiling adds to the RUNPATH in
the .so file:
cc -shared -fPIC -DPIC -o .libs/Parsetexi.so
parsetexi/.libs/Parsetexi_la-Parsetexi.o
-L/home/gavin/texinfo-7.1.91/build/tp/Texinfo/XS/.libs -L./.libs -ltexinfoxs
-L/usr/local/lib -ltexinfo -lintl -lunistring -liconv -fstack-protector-strong
-O2 -Wl,-R/usr/libdata/perl5/mips64-openbsd/CORE -Wl,-R
/home/gavin/texinfo-7.1.91/build/tp/Texinfo/XS/.libs
I added the final -Wl,-R option from what was output by automake/libtool.
Then readelf shows:
0x000000000000000f (RPATH) Library rpath: [/usr/libdata/perl5/mips
64-openbsd/CORE:/home/gavin/texinfo-7.1.91/build/tp/Texinfo/XS/.libs]
0x000000000000001d (RUNPATH) Library runpath:
[/usr/libdata/perl5/mips64-openbsd/CORE:/home/gavin/texinfo-7.1.91/build/tp/Texinfo/XS/.libs]
Then the run of texi2any successfully loads the XS modules (in fact,
all of them, probably because Parsetexi.so was the first module loaded
which pulled in -ltexinfo and -ltexinfoxs). After rebuilding without this
extra option, it fails again.
So it seems in theory, libtool and/or automake could be fixed to
provide this extra option or something like it.
I don't know, would it be possible to load libtexinfo and libtexinfoxs
directly with Texinfo::XSLoader before loading any other modules?
Then these libraries are in the "address space" of the perl process and
shouldn't need to be loaded again. I am going to try to do this as it
seems like it could be an easy fix.
> 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.
The only concern I have is if tests pass when run with pure Perl modules,
but the XS modules are actually used after installation, we are failing
to test those modules and there could be a hidden bug.
