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
