On 30/06/2020 18:47, Eli Zaretskii wrote: >> Date: Tue, 30 Jun 2020 18:44:32 +0300 >> From: Eli Zaretskii <eliz****@gnu*****> >> >>> Date: Tue, 30 Jun 2020 18:09:08 +0300 >>> From: Eli Zaretskii <eliz****@gnu*****> >>> >>> So basically, I think that we must provide in libmingwex the wchar.h >>> functions that might not be available in MSVCRT.DLL, so that programs >>> could reliably work on XP and older systems. >> >> I'm no longer sure this conclusion is correct. > > Or maybe I do. > > This factoid seems to be relevant: previously I used MinGW runtime > 5.2.1, where libmingwex had both btowc and mbrtowc. But in MinGW > runtime 5.3.1, which is what I have now, libmingwex doesn't have those > functions, and instead has __msvcrt_btowc and __msvcrt_mbrtowc. So if > a program is linked with a library that includes btowc and mbrtowc as > unresolved externals, the linker would find it in libmingwex 5.2.1, > but not in libmingwex 5.3.1. The result, predictably, is that in GDB > 9.1, which was compiled with mingwrt-5.2.1, I see the code of btowc > from libmingwex, whereas in GDB 10 compiled with mingwrt-5.3.1 I see > an indirect call to MSVCRT's btowc instead. > > Does this sound like the correct explanation for what I'm > experiencing? I'm not sure that I entirely follow your logic here; maybe it does, but I'm not convinced. I think we can agree on this: - Compile with <wchar.t> from mingwrt-5.2.x, and the object module will contain an unresolved symbol reference for btowc; _link_ that with mingwrt-5.2.x libraries, and that reference will be resolved to the implementation in libmingwex.a, (or libmingwex.dll.a), but link with mingwrt-5.3.x, and the link _should_ fail, (because the btowc symbol isn't present in libmingwex.a, or libmingwex.dll.a, and nor _should_ there be a fall-back in libmsvcrt.a ... but wait; there _is_ such a fall-back, and therein lies the explanation for your problem ... the linker believes that it can resolve the btowc symbol from MSVCRT.DLL, which isn't the case prior to Win-Vista, (and even from Vista onward, we want to ignore it). - Compile with <wchar.h> from mingwrt-5.3.x, and the object module will contain an unresolved reference to __msvcrt_btowc; link that with mingwrt-5.3.x libraries, an linking should succeed, but with mingwrt-5.2.x libraries, it _must_ fail. 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. -- 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/20200630/e9423778/attachment-0001.sig>
Fork