Thanks for the info. Now I see that affected files are compiled twice and only the second compilation fails.
I will try to find out what causes iconv-2.dll to export sprintf. It should at least give us some answers. - Kirill Makurin ________________________________ From: Bruno Haible <br...@clisp.org> Sent: Monday, June 16, 2025 8:56 AM To: Kirill Makurin <maiddais...@outlook.com> Cc: bug-gnulib@gnu.org <bug-gnulib@gnu.org> Subject: Re: clang-cl: undeclared library function 'sprintf' Kirill Makurin wrote: > I tried further investigate this issue and I have discovered that > libtextstyle/lib/config.h contains following lines: > > ``` > #define sprintf libtextstyle_sprintf > #define sscanf libtextstyle_sscanf > ``` > > Since config.h is included before any system header file, later when system's > stdio.h is included, I assume this macro is defined and instead of > declaring/defining inline sprintf it ends up declaring/defining > libtextstyle_sprintf. What you are seeing here is similar to what you saw with iconv-2.dll: These config.h lines get generated by libtextstyle/lib/Makefile.am: In a first pass all object files are compiled without these #defines, then the exported symbols of these files (look at the file 'exported.sh') are collected and remapped to symbols with a 'libtextstyle_' prefix. So, it means that during this first pass, at least one object file had 'sprintf' as an exported symbol, and likewise for 'sscanf'. libiconv does not have this same compilation-in-two-passes technique; this is why there the symbol 'sprintf' is exported without a prefix. Still, the origin seems to be the same: the MSVC headers must contain some inlinable definition of sprintf and sscanf, and your 'clang-cl' must be stuffing these into the object files as exported symbols. Which, as you noted, is a no-go for shared libraries. Bruno
