Re: btowc problem

Keith Marshall <[email protected]> Tue, 30 Jun 2020 21:33:14 +0100
Newsgroups	gmane.comp.gnu.mingw.user
Organization	MinGW.org Project
Message-ID	<[email protected]>
On 30/06/2020 18:47, Eli Zaretskii wrote:
>> Date: Tue, 30 Jun 2020 18:44:32 +0300
>> From: Eli Zaretskii <eliz-mXXj517/[email protected]>
>>
>>> Date: Tue, 30 Jun 2020 18:09:08 +0300
>>> From: Eli Zaretskii <eliz-mXXj517/[email protected]>
>>>
>>> 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

_______________________________________________
MinGW-Users mailing list
[email protected]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.osdn.me/mailman/listinfo/mingw-users
Also: mailto:[email protected]?subject=unsubscribe
signature.asc (application/pgp-signature, 833 B)