> Date: Thu, 10 Oct 2024 23:57:56 +0200 > From: Patrice Dumas <[email protected]> > Cc: [email protected] > > 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.
