On Sun, Nov 17, 2024 at 10:14:37PM +0100, Patrice Dumas wrote:
> On Sun, Nov 17, 2024 at 09:37:23PM +0100, Patrice Dumas wrote:
> > I have added a report for all the platforms tested in the CI. It
> > appears that cygwin, both 32 and 64 bits and OpenBSD unexpectedly cannot
> > load Parsetexi.so/dll (in addition to macos 12 and macos 13). MiscXS is
> > loaded in all the platform, so it is not a basic issue with XS, but
> > something else.
>
> I couldn't find what was going on. The directories may not be the right
> ones, but otherwise I can't see what's wrong. For openbsd, for example,
> the link commands looks good:
>
> libtool: link: cc -shared -fPIC -DPIC -o .libs/Parsetexi.so
> parsetexi/.libs/Parsetexi_la-Parsetexi.o
> -L/home/runner/work/ci-check/ci-check/texinfo-7.1.91.20241117/build/tp/Texinfo/XS/.libs
> -L/usr/local/lib -L./.libs -ltexinfoxs -ltexinfo -fstack-protector-strong
> -O2 -Wl,-R/usr/libdata/perl5/amd64-openbsd/CORE
>
Here are some notes from my attempts to investigate the issue this
evening, although I did not solve the issue and I feel like it may be
beyond us to fix without asking for help from experts on libtool and/or
experts on the operating systems in question.
As you said, MiscXS is loaded, as is TestXS when the configure script
runs (otherwise the XS modules would be disabled). So it appears to be
an issue with the library dependencies of the XS modules themselves.
On my GNU/Linux system (Linux Mint 21.2 Xfce, Linux 5.19.0 x86_64), the
corresponding command is:
libtool: link: x86_64-linux-gnu-gcc -shared -fPIC -DPIC
parsetexi/.libs/Parsetexi_la-Parsetexi.o -Wl,-rpath
-Wl,/home/g/src/texinfo/GIT/tp/Texinfo/XS/.libs -Wl,-rpath
-Wl,/usr/local/lib/texi2any -L/home/g/src/texinfo/GIT/tp/Texinfo/XS/.libs
./.libs/libtexinfoxs.so
/home/g/src/texinfo/GIT/tp/Texinfo/XS/.libs/libtexinfo.so ./.libs/libtexinfo.so
-O2 -g -Wl,-E -Wl,-soname -Wl,Parsetexi.so -o .libs/Parsetexi.so
libtool: link: ( cd ".libs" && rm -f "Parsetexi.la" && ln -s "../Parsetexi.la"
"Parsetexi.la" )
What may explain the difference is the "-ltexinfoxs -ltexinfo" flags in
the macos case. This does not appear in the GNU/Linux output: instead,
the libraries are listed by name ("./.libs/libtexinfoxs.so"). (Or this
could just be an expected difference due to a different compiler being used.)
I got access to an OpenBSD system (OpenBSD 7.5, Cavium OCTEON (rev 0.2)) as
you said it was also an issue on OpenBSD. Here the output from building
Parsetexi.la is as follows:
$ rm Parsetexi.la
$ make Parsetexi.la
/bin/sh ./libtool --tag=CC --mode=link cc -DNO_LOCALE_NUMERIC
-DNO_LOCALE_COLLATE -fno-strict-aliasing -fno-delete-null-pointer-checks -pipe
-fstack-protector-strong -I/usr/local/include -O2 -DPIC -fpic -avoid-version
-module -Wl,-R/usr/libdata/perl5/mips64-openbsd/CORE -o Parsetexi.la -rpath
/usr/local/lib/texi2any parsetexi/Parsetexi_la-Parsetexi.lo libtexinfoxs.la
libtexinfo.la
libtool: link: rm -fr .libs/Parsetexi.la .libs/Parsetexi.lai .libs/Parsetexi.so
libtool: link: 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
libtool: link: ( cd ".libs" && rm -f "Parsetexi.la" && ln -s "../Parsetexi.la"
"Parsetexi.la" )
On OpenBSD, in Parsetexi.la, relink_command is given:
relink_command="(cd /home/gavin/texinfo-7.1.91/build/tp/Texinfo/XS; /bin/sh
\"/home/gavin/texinfo-7.1.91/build/tp/Texinfo/XS/libtool\" --tag CC
--mode=relink cc -DNO_LOCALE_NUMERIC -DNO_LOCALE_COLLATE -fno-strict-aliasing
-fno-delete-null-pointer-checks -pipe -fstack-protector-strong
-I/usr/local/include -O2 -DPIC -fpic -avoid-version -module
-Wl,-R/usr/libdata/perl5/mips64-openbsd/CORE -o Parsetexi.la -rpath
/usr/local/lib/texi2any parsetexi/Parsetexi_la-Parsetexi.lo libtexinfoxs.la
libtexinfo.la @inst_prefix_dir@)"
While testing texi2any, I accidentally found a bug:
$ export top_srcdir=../../ top_builddir=.. TEXINFO_DEV_SOURCE=1
$ ./texi2any ../doc/info-stnd.info
texi2any: warning: input file info-stnd.info; did you mean info-stnd.texi?
You found a bug: Should be at end of line but have [inde]
'
Additional information:
last location: info-stnd.info:2106
context_stack: (ct_base)
current: (before_node_section)[C1078] at ../../tp/Texinfo/ParserNonXS.pm line
1144.
Died at ../../tp/Texinfo/ParserNonXS.pm line 7647.
TEXINFO_XS=debug reveals similar problems to the one you had with
macOS:
checking ../../tp/maintain/lib/Text-Unidecode/lib/Parsetexi.la
checking ../../tp/maintain/lib/Unicode-EastAsianWidth/lib/Parsetexi.la
checking ../../tp/maintain/lib/libintl-perl/lib/Parsetexi.la
checking ../tp/Texinfo/XS/Parsetexi.la
found ../tp/Texinfo/XS/Parsetexi.la
additional libraries: -ltexinfoxs|-ltexinfo
found additional:
Parsetexi: couldn't load file ../tp/Texinfo/XS/.libs/Parsetexi.so: Cannot load
specified object at ../../tp/Texinfo/XSLoader.pm line 191, <$fh> line 8.
falling back to pure Perl module Texinfo::ParserNonXS
There is no "otool" command on this system and "ldd" doesn't seem to
work:
$ ldd Texinfo/XS/.libs/Parsetexi.so
Texinfo/XS/.libs/Parsetexi.so:
Cannot load specified object
Texinfo/XS/.libs/Parsetexi.so: exit status 1
(I'm probably doing something wrong.) Eventually I discovered the
"readelf" command. In the output of "readelf -a .libs/Parsetexi.so"
there is:
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.
I thought I would try with "make install" to see what libtool did with
the .so files:
$ make install DESTDIR=/home/gavin/dest
...
libtool: warning: relinking 'Parsetexi.la'
libtool: install: (cd /home/gavin/texinfo-7.1.91/build/tp/Texinfo/XS; /bin/sh
"/home/gavin/texinfo-7.1.91/build/tp/Texinfo/XS/libtool" --tag CC
--mode=relink cc -DNO_LOCALE_NUMERIC -DNO_LOCALE_COLLATE -fno-strict-aliasing
-fno-delete-null-pointer-checks -pipe -fstack-protector-strong
-I/usr/local/include -O2 -DPIC -fpic -avoid-version -module
-Wl,-R/usr/libdata/perl5/mips64-openbsd/CORE -o Parsetexi.la -rpath
/usr/local/lib/texi2any parsetexi/Parsetexi_la-Parsetexi.lo libtexinfoxs.la
libtexinfo.la -inst-prefix-dir /home/gavin/dest)
libtool: relink: 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/home/gavin/dest/usr/local/lib/texi2any -L/usr/local/lib/texi2any -ltexinfoxs
-L/usr/local/lib -ltexinfo -L/home/gavin/dest/usr/local/lib -lintl -lunistring
-liconv -fstack-protector-strong -O2
-Wl,-R/usr/libdata/perl5/mips64-openbsd/CORE
libtool: install: /usr/bin/install -c .libs/Parsetexi.soT
/home/gavin/dest/usr/local/lib/texi2any/Parsetexi.so
libtool: install: /usr/bin/install -c .libs/Parsetexi.lai
/home/gavin/dest/usr/local/lib/texi2any/Parsetexi.la
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.
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.
> 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?
