On Fri, Oct 11, 2024 at 08:27:10AM +0300, Eli Zaretskii wrote: This requires a direct access to the platform, which I have not. I will add the link to your mail in the CI and somewhere in Texinfo to help a tester who would want to debug further.
> You can verify that element_command_name is indeed in libtexinfo.dll.a > by using 'nm': > > nm -A ./.libs/libtexinfo.dll.a | fgrep element_command_name > > If the above tells you element_command_name is indeed in the import > library, run "nm -A" on main/.libs/libtexinfoxs_la-build_perl_info.o > and compare the exact name of the unresolved symbol linker should > resolve with what you see in libtexinfo.dll.a, maybe there's some > discrepancy, like a leading underscore. > Also, does Perl call our XS code in some way? If it does, then you > may need to move ./.libs/libtexinfo.dll.a _after_ -lperl, or maybe > even have one before -lperl and one more after it. Perl calls our XS code in some way, but not this library. > Finally, I'd remove the -O3 and -fstack-protector-strong switches from > the compiler and linker switches, who knows what they do. Not sure > this is related to your problems. I think that these are flags used for Perl compilation, which we use when we compile code that it linked against Perl. I don't think that it is related to our failure, but maybe it could be relevant to add a possibility to avoid them. I think that we should wait for actual issues, though, as this part is complicated enough. > P.S. Is libtexinfo.dll.a under ./.libs or under ./main/.libs ? IOW, > are there indeed two separate .libs subdirectories involved? If not, > maybe that's your problem. All the lib*.la, and also the .so dlopened by Perl are in ./.libs. The source files and .o may be in the tp/Texinfo/XS directory or (more often) in tp/Texinfo/XS subdirectories. Why would there be an issue if there are not two directories? Thanks in any case. -- Pat
