On 01/07/2020 16:08, Eli Zaretskii wrote: > From: Keith Marshall <keith****@users*****> > Date: Tue, 30 Jun 2020 21:33:14 +0100 >> And ... in writing this, I think I've walked into the real explanation, >> which in turn leads to the solution: we need to rebuild libmsvcrt.a, >> omitting the offending symbols -- i.e. all of those which we want to be >> accessed exclusively via __msvcrt_redirect references in libmingwex.a. > > 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. > Those older libraries will want to resolve btowc and the other > wchar.h functions which were previously in libmingwex. If you want > libmsvcrt.a to solve this, you will have to put in there btowc etc. > that call back into libmingwex.a's __msvcrt_* versions, no? And that > would make libmsvcrt.a not really an import library anymore, although > maybe we don't care?> > 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. 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. [*] 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(). -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20200701/ed11184f/attachment-0001.sig>
Fork