On Fri, Feb 27, 2026 at 11:19:59AM +0100, Bruno Haible wrote: > This is because the definition of DLL_VARIABLE (__declspec(dllexport) vs. > __declspec(dllimport)) depends on whether the current compilation unit will > end up inside or outside that shared library. The boundaries of the shared > library are package-specific; they depend on which code is included via > lib..._la_SOURCES += sourcecode.c
Something that I really do not understand is why this issue does not happen for some variables in the texinfo libraries used by the XS modules objects. I found one that should have triggered some similar crash in the tests of Perl code dlopening both the XS module object and the texinfo library, and there are other. One such symbol I found is translated_special_unit_info, declared in C/convert/html_converter_types.h: extern const TRANSLATED_SUI_ASSOCIATION translated_special_unit_info[]; defined in C/main/html_conversion_data.c, which is part of the libtexinfo library. It is used in perl/XSTexinfo/convert/get_html_perl_info.c in html_converter_init_special_unit_sv, compiled in ConvertXS module object. The html_converter_init_special_unit_sv is called in ConvertXS.xs html_converter_get_customization_sv, which is called by every call to the Perl HTML converter initialization when XS is enabled. Therefore, the translated_special_unit_info symbol seems to be in two different compilation units, and should be used in a function called in tests, and yet there is no failure. I wanted to add __declspec(dll*) to such extern objects being a variable used outside of their compiled object, but now I am not sure that it is needed. -- Pat
