> From: Keith Marshall <keith****@users*****> > Date: Wed, 1 Jul 2020 22:14:54 +0100 > > > I'm probably missing something, but how can this work if one links a > > program compiled under mingwrt-5.3.x, but with some libraries compiled > > by older mingwrt? > > It can't; but that's the point ... we don't want it to. Like it or not, > mixing libraries across versions is asking for trouble. But disallowing that is harsh: it means I'll need to rebuild every single library I ever built with the new runtime. And the new DLLs I rebuild will then cease to work for the programs I built with the old runtime. Which means I will need to rebuild every single MinGW program I have on this system. If that is the final verdict, I'd rather downgrade to MinGW runtime 5.2.x and stay with it indefinitely. However, I hope we will be able to find some solution that avoids this and still allows use of 5.3.x and later runtimes. > > My suggestion was to add to 5.3.x libmingwex.a implementations of > > btowc etc. that simply call the corresponding __msvcrt_* functions, so > > that libraries compiled by older MinGW versions could still be happy > > when linked under the newer mingwrt. > > No, that cannot work; it would create a recursive call loop with no > terminal condition, until the process runs out of stack space. You are saying that __msvcrt_* functions call btowc etc.? I thought they were doing that via a function pointer, which gets populated at run time? > If we must maintain cross-version compatibility, then we must accept > that all of the MSVCRT.DLL -- and MSVCRn.DLL -- implementations of > btowc, mbrlen, mbrtowc, mbsrtowcs, wctob, wcrtomb, and wcsrtombs are > unfit for purpose, (which I suspect to be the case anyway[*]), and > not attempt to use them under any circumstances, and just use the > libmingwex.a implementations exclusively. OK. Is that possible with the current mingwrt-5.3.x? If so, how do I modify the compilation to achieve that? And if that's not currently possible, then what changes would be needed to achieve it? > [*] I had my doubts about delegating to MSVCRT.DLL implementations of > any of these functions, because Microsoft's choice of UTF-16LE as the > underlying representation of wchar_t precludes any one-to-one mapping of > any possible Unicode code point to a single wchar_t, (as is required for > ISC-C99 conformance), and Microsoft's online documentation conveniently > neglects to mention the limitation. This discussion is convincing me > that my doubt was vindicated, and we should revert to use of our MinGW > implementations exclusively, (but using the new implementations, because > they did address some failings of their predecessors); thus, functions > in this group, in mingwrt-5.3.x, named __msvcrt_foo() and corresponding > __mingw_foo() would disappear, to be consolidated into foo(). Fine with me, thanks. The MS wchar_t and its limitations are well known to me, they actually make some very important functionality unavailable on Windows for characters outside the BMP, even if you use the wide-character CRT functions.
Fork