On Sunday 15 February 2026 20:41:54 LIU Hao wrote: > 在 2026-2-4 07:19, Kirill Makurin 写道: > > What about this one? Will you re-send this one with a commit message or > > would you like to investigate this a little more? > This patch: > > > From a8a982c43a8e5117653f5b75920d07cf7e237747 Mon Sep 17 00:00:00 2001 > > From: Kirill Makurin <[email protected]> > > Date: Sat, 17 Jan 2026 19:43:19 +0900 > > Subject: [PATCH 09/10] Try fix C++ linking > > > > --- > > mingw-w64-crt/Makefile.am | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am > > index 22f0bd5a7d0f..3b81a53b0796 100644 > > --- a/mingw-w64-crt/Makefile.am > > +++ b/mingw-w64-crt/Makefile.am > > @@ -195,6 +195,7 @@ src_msvcrt_common=\ > > stdio/snwprintf_alias.c \ > > stdio/swprintf.c \ > > stdio/swprintf_alias.c \ > > + stdio/vsnprintf.c \ > > stdio/vsnprintf_alias.c \ > > stdio/vsnwprintf_alias.c \ > > stdio/vswprintf.c \ > > @@ -440,6 +441,7 @@ src_ucrtbase=\ > > misc/output_format.c \ > > misc/ucrt-access.c \ > > stdio/msvcr80plus_ftruncate64.c \ > > + stdio/vsnprintf.c \ > > stdio/ucrt___local_stdio_printf_options.c \ > > stdio/ucrt___local_stdio_scanf_options.c \ > > stdio/ucrt__scprintf.c \ > > @@ -1291,7 +1293,7 @@ src_libmingwex=\ > > \ > > stdio/snprintf.c stdio/snwprintf.c stdio/truncate.c > > stdio/truncate64.c \ > > stdio/ulltoa.c stdio/ulltow.c stdio/vasprintf.c \ > > - stdio/vsnprintf.c stdio/vsnwprintf.c \ > > + stdio/vsnwprintf.c \ > > stdio/wtoll.c stdio/mingw_asprintf.c > > stdio/mingw_vasprintf.c > > # these go into both 32 and 64 bit x86 versions: > > -- > > 2.20.1 > > attempts to move `__ms_vsnprintf()` from libmingwex into CRT libraries. > While this looks safe in general, what specific issue does it solve?
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. > And in > the context of this change there are three more files: stdio/snprintf.c, > stdio/snwprintf.c and stdio/vsnwprintf.c, and why isn't the same done with > them? We have hit this problem with vsnprintf usage. We did not have at that time code which called snprintf / snwprintf / vsnwprintf. So probably these functions would hit same issue. At that time we have tried to quickly address compiler and linker errors which we hit. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
