On Sun, Nov 17, 2024 at 07:41:37PM +0100, Patrice Dumas wrote:
> Hello,
>
> I noticed that the macos parser runs the tests with the Pure Perl parser
> in the CI, although for macos 12 and macos 13 it seemed that everything
> was going on well regarding compilation. I could reproduce this issue
> with an access to this platform.
>
> Launching texi2any.pl with TEXINFO_XS=debug shows the issue:
> 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
> Parsetexi: couldn't load file ../tp/Texinfo/XS/.libs/Parsetexi.so:
> dlopen(../tp/Texinfo/XS/.libs/Parsetexi.so, 0x0001): Library not loaded:
> '/usr/local/lib/texi2any/libtexinfoxs.0.dylib'
> Referenced from: '..../texinfo/tp/Texinfo/XS/.libs/Parsetexi.so'
> Reason: tried: '/usr/local/lib/texi2any/libtexinfoxs.0.dylib' (no such
> file), '/usr/local/lib/libtexinfoxs.0.dylib' (no such file),
> '/usr/lib/libtexinfoxs.0.dylib' (no such file) at ../tp/Texinfo/XSLoader.pm
> line 183, <$fh> line 8.
>
> The problem is that libtexinfoxs.0.dylib is only searched for in the
> directory where it will be installed, not in the build directory. My
> feeling is that it is wrong. My intuition would be that it is an issue
> with libtool but I am not sure. I have checked that
> ../tp/Texinfo/XS/.libs/ is in @DynaLoader::dl_library_path and that
> libtexinfoxs.0.dylib is in ../tp/Texinfo/XS/.libs/.
It does look like a bug somewhere. It could be an issue with how
libtool treats this platform. I know that it is frequent for libtool
libraries to be "re-linked" at the time of installation to work in their
installed locations. Here it appears that the library is in its final,
installed form before being installed.
On GNU/Linux I can run a command on .libs/Parsetexi.so:
ldd Parsetexi.so
linux-vdso.so.1 (0x00007ffe2e98c000)
libtexinfoxs.so.0 =>
/home/g/src/texinfo/GIT/tp/Texinfo/XS/.libs/libtexinfoxs.so.0
(0x00007f1940f28000)
libtexinfo.so.0 =>
/home/g/src/texinfo/GIT/tp/Texinfo/XS/.libs/libtexinfo.so.0 (0x00007f1940e4f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1940c00000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1940f82000)
If you could do something similar on macos it could help to investigate
the problem.
Parsetexi.la has the line:
relink_command="(cd /home/g/src/texinfo/GIT/tp/Texinfo/XS; /bin/bash
\"/home/g/src/texinfo/GIT/tp/Texinfo/XS/libtool\" --tag CC --mode=relink
x86_64-linux-gnu-gcc -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -g -fPIC -avoid-version -module -Wl,-E -o
Parsetexi.la -rpath /usr/local/lib/texi2any parsetexi/Parsetexi_la-Parsetexi.lo
libtexinfoxs.la libtexinfo.la @inst_prefix_dir@)"
This shows it needs to be relinked.
The contents of libtexinfoxs.la could also be relevant and might give
some hints why the installed locations are being used.
>
> It is not so problematic, as the pure Perl can be used and I do not
> believe that there are that many users on macos, so I do not think that
> it should delay a release, but it should probably be fixed some day.
> Also it could be possible that the BSD have the same issue, I'll try to
> investigate a bit using the CI.
>
> --
> Pat
>
