On Monday 26 January 2026 12:49:46 Kirill Makurin wrote:
> LIU Hao wrote:
> >在 2026-1-26 20:20, Kirill Makurin 写道:
> >> LIU Hao wrote:
> >>> 在 2026-1-26 07:16, Pali Rohár 写道:
> >>>> C++ header files are trying to put quick_exit and at_quick_exit functions
> >>>> into :: or std:: namespace. If those functions are not declared then
> >>>> compilation is failing with error:
> >>>> error: 'at_quick_exit' has not been declared in '::'
> >>>> And it does not matter if those functions are used or not.
> >>>> ---
> >>>> mingw-w64-headers/crt/stdlib.h | 4 ----
> >>>> 1 file changed, 4 deletions(-)
> >>>
> >>> DI such headers exist in the wild? Both libstdc++ and libc++ declare them
> >>> conditionally.
> >>
> >> This is probably resulted from the fact that we were using libstdc++
> >> headers configured for UCRT when we run tests for msvcrt{20,40}.dll, note
> >> condition "matrix.crt == ucrt":
> >
> > That's unsupported, even more unsupported than using MSVCRT headers but
> > linking against a non-default CRT
> > DLL.
> >
> >> maybe using "matrix.crt == msvcrt" instead would solve this issue? This
> >> also means that we are linking static libstdc++ configured for UCRT when
> >> running tests for msvcrt{20,40}.dll, which may result in more issues in
> >> future.
> >
> > You can try that; but if libstdc++ tests can never pass with such old DLLs,
> > we cannot have such setups on
> > the CI.
What is important t say is that all tests with those changes passed both
locally and on github CI. So I think that this can be a good measurement.
And the change in mingw-w64 stdlib.h was rather trivial to make
compilation happy, so I thought that this is something which could be
useful.
But I understand your concerns.
> This is really problematic. We're doing this only when running `make check`
> for mingw-w64's tests and we link libstdc++ statically; otherwise, C++ tests
> would be linked against CRT we are testing (msvcrt20.dll or msvcrt40.dll) and
> libstdc++, which is linked against CRT specified by `matrix.crt`. The latter
> is even more mess.
>
> One possible solution is to pass `-mcrtdll=` flag only for C compilations.
> Another, more complicated but seemingly correct solution is to configure
> libstdc++ for msvcrt{20,40}.dll.
I would suggest to not mix different CRT DLL libs in one EXE file.
This is not only unsupported but also it would cause crashes for sure.
Passing FILE* retrieved from UCRT fopen() cannot be passed to msvcrt
fprintf().
On the other hand, compiling everything statically (without linking to
any particular CRT) and then linking all static libs into one executable
with one CRT DLL, should be relatively safe. In the worst case there
would be linker errors, not runtime errors like passing of wrong
structures between CRTs.
> >> Pali picked this commit from branch where we were running CI tests. There
> >> were link issues with undefined reference to __ms_vsnprintf and it seemed
> >> to do with link order. I initially pushed that commit just to see if it'll
> >> fix the issue.
> >
> > So what should I do? Drop it?
>
> Pali would explain the purpose of this commit better than me. I suggest this
> one has to be re-sent with commit message.
>
> - Kirill Makurin
This change is needed to fix linking issues.
Kirill should have older linker error logs on github CI. In the worst
case we can reproduce it locally or again on github CI.
I'm not exactly sure what is the issue, but symptoms are that GNU LD
linker was not able to find the __ms_vsnprintf symbol and thrown error.
I saw similar issues related to GCC and GNU LD when LTO was enabled.
When I tried to link with -lLIB1 -lLIB2 and the LIB2 used symbol from
LIB1 then _sometimes_ linker thrown error. And the fix was to either use
--start-group / --end-group switches to LD, or to move the symbols from
LIB1 to LIB2, so LIB2 would not depend on LIB1.
In our case, error happened with static linked libstdc++ and my idea is
that statically linked libstdc++ is calling vsnprintf function (which is
in libmsvcrtNN.a compiled from mingw-w64-crt/stdio/vsnprintf_alias.c)
and it calls the __ms_vsnprintf function (which is in libmingwex.a
compiled from mingw-w64-crt/stdio/vsnprintf.c).
My idea was that libmsvcrtNN.a could not call libmingwex.a functions due
to linking order, so I suggested to move the __ms_vsnprintf function
from the libmingwex.a to all libmsvcrtNN.a and libucrt.a libraries.
And with this change, github CI successfully linked all test executables
and stopped throwing errors.
I'm really not sure if this is the exact reason why linking error
happened but for me it sounds plausible that in some cases gcc/ld is not
happy when libmsvcrt.a tries to reference libmingwex.a symbols.
I could write commit message and/or resend this change separately.
Just let me know if you have other idea where could be the problem or
how to fix it in different way.
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
