Re: strange build failure for cygwin32 in CI

[Eli Zaretskii]

> Date: Thu, 10 Oct 2024 23:57:56 +0200
> From: Patrice Dumas <pertusus@free.fr>
> Cc: bug-texinfo@gnu.org
> 
> I modified the build such that -lperl is now after libtexinfo.dll.a:
> 
> libtool: link: gcc -shared  main/.libs/libtexinfoxs_la-build_perl_info.o 
> main/.libs/libtexinfoxs_la-get_perl_info.o 
> main/.libs/libtexinfoxs_la-options_get_perl.o   -lintl 
> ./.libs/libtexinfo.dll.a -L/usr/lib/perl5/5.32/i686-cygwin-threads-64int/CORE 
> -lperl  -ggdb -O2 -fstack-protector-strong -O3   -o .libs/cygtexinfoxs-0.dll 
> -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker 
> .libs/libtexinfoxs.dll.a
> 
> However this does not work better.  I still get errors like:
> /usr/lib/gcc/i686-pc-cygwin/11/../../../../i686-pc-cygwin/bin/ld: 
> main/.libs/libtexinfoxs_la-build_perl_info.o: in function 
> `element_to_perl_hash':
> /cygdrive/d/a/ci-check/ci-check/texinfo-7.1.90-20241010/build/tp/Texinfo/XS/../../../../tp/Texinfo/XS/main/build_perl_info.c:801:
>  undefined reference to `element_command_name'
> 
> element_command_name is in main/builtin_commands.c and therefore should
> be in ./.libs/libtexinfo.dll.a.

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.

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.

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.

If nothing else helps, I suggest to add -v to the failing link
command, and look at the detailed information output by the linker
regarding the libraries it searches and their directories -- maybe
that will provide a hint.