Re: strange build failure for cygwin32 in CI

[Patrice Dumas]

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