On Sunday 15 February 2026 23:32:25 LIU Hao wrote:
> 在 2026-2-15 23:07, Pali Rohár 写道:
> > When we tested some C++ code which called vsnprintf() we got linking
> > errors. And when we moved the __ms_vsnprintf symbol from libmingwex.a to
> > msvcrt import library then liking error about the __ms_vsnprintf missing
> > symbol disappeared and linker correctly generated output binary.
> >
> > By observing this behavior, my idea was that it is because of library
> > linking order, which is hardcoded in gcc spec file. And that it is
> > better if the msvcrt/ucrt import library does not call functions from
> > libmingwex.a library.
>
> It sounds like that `__ms_vsnprintf()` is called in one of the mingw-w64
> default libraries after libmingwex.
See mingw-w64-crt/stdio/vsnprintf_alias.c file where is:
int __cdecl vsnprintf(char *buffer, size_t n, const char *format, va_list arg)
{
return __ms_vsnprintf(buffer, n, format, arg);
}
> If that happens, then such a call should
> be considered a bug and should be deleted.
It was added by Martin to fix another C++ linking bug.
Moreover this usage cannot be deleted because for example autoconf is
checking for vsnprintf symbol existence by trying to link test
application without including any header file. So any usage of vsnprintf
without header file can trigger inclusion of vsnprintf_alias.o object
file and then the __ms_vsnprintf symbol which is currently in
libmingwex.a.
For me it looks like that vsnprintf_alias.c and vsnprintf.c should be in
the same .a import library to prevent those linking problems.
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
