On 5/29/20 2:04 PM, Liu Hao via Gcc-patches wrote:
> 在 2020/5/29 22:01, Liu Hao 写道:
>> This is necessary as libmsvcrt.a is not a pure import library, but
>> also contains some functions that invoke others in KERNEL32.DLL.
>>
>> * config/i386/mingw32.h: Insert -lkernel32 after -lmsvcrt
>> ---
>> gcc/config/i386/mingw32.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h
>> index 1bbabfe8bed..321c30e41cc 100644
>> --- a/gcc/config/i386/mingw32.h
>> +++ b/gcc/config/i386/mingw32.h
>> @@ -165,7 +165,7 @@ along with GCC; see the file COPYING3. If not see
>> #define REAL_LIBGCC_SPEC \
>> "%{mthreads:-lmingwthrd} -lmingw32 \
>> " SHARED_LIBGCC_SPEC " \
>> - -lmoldname -lmingwex -lmsvcrt"
>> + -lmoldname -lmingwex -lmsvcrt -lkernel32"
>> #undef STARTFILE_SPEC
>> #define STARTFILE_SPEC "%{shared|mdll:dllcrt2%O%s} \
>>
>
> This patch originates from this discussion on #mingw-w64 on OFTC:
>
> ```
> [20:09:50] <lh_mouse> there is suddenly an unexpected call to
> `IsDBCSLeadByteEx()` in winpthreads. Not sure why it gets involved.
> [20:13:12] * tchan (~tc...@c-98-220-238-152.hsd1.il.comcast.net) has joined
> [20:22:28] <lh_mouse> diff'ing the import tables the previous working
> binary and now broken binary reveals that the old symbol to `printf` is
> gone. seems the mingw-w64 ones is called, which references
> `IsDBCSLeadByteEx()` and `WideCharToMultiByte()`.
> [20:27:19] <wbs> both of those should be provided by -lkernel32 right?
> [20:27:36] * Dejan has quit (Quit: Leaving)
> [20:34:09] <lh_mouse> probably, but I doubt whether it should behave
> this way. when perform cross-compilation the CRT is not available when
> building winpthreads.
> [20:34:37] <lh_mouse> presumably it should always call the MS one.
> [20:34:45] <wbs> I'm pretty sure you'd first build the crt, then
> libraries like winpthreads - the other way around doesn't work
> [20:35:16] <lh_mouse> :| let me make a test program.
> [20:38:38] <lh_mouse> can't reproduce it myself.
> [20:41:06] <lh_mouse> there may be something wrong with the OP'
> [20:41:18] <lh_mouse> 's configuration. Normally kernel32 is a default lib.
> [20:42:39] <lh_mouse> I still think winpthreads should be built with
> `CPPFLAGS='-D__USE_MINGW_ANSI_STDIO=0'`. I built a local package and
> there is no reference to DBCS or wide char functions.
> [20:49:21] <lh_mouse> reproduced now:
> https://paste.ubuntu.com/p/HwNk8WqgkD/
> [20:49:23] <minifox> Title: Ubuntu Pastebin (at paste.ubuntu.com)
> [20:52:45] <lh_mouse> strange: -lmingw32 -lgcc -lgcc_eh -lmoldname
> -lmingwex -lmsvcrt -lpthread -lmcfgthread -ladvapi32 -lshell32 -luser32
> -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt
> [20:53:10] <lh_mouse> oh.
> [20:53:22] <lh_mouse> the mingw-w64 `printf` is defined in mingwex I guess?
> [20:53:22] <wbs> pthread pulls in objects from msvcrt, which then needs
> things from kernel32, but there's no more kernel32 after msvcrt
> [20:54:04] <wbs> in 211af1e7d4d188dbefacea7af8b83d32b3edb48c I moved
> mbrtowc and wcrtomb from mingwex to msvcrt
> [20:54:37] <wbs> (but that wouldn't make a difference wrt this, as
> there's no kernel32 after the first mingwex after -lpthread either)
> [20:55:10] <wbs> I think it would be good with yet another -lkernel32
> after -lmsvcrt
> [20:55:27] <wbs> after all, that's the way they are layered anyway - the
> crt runs on top of kernel32
> [20:56:32] <wbs> and we want to have the freedom to have object file
> implementations in libmsvcrt.a
> [20:58:21] <lh_mouse> some of these -l things are hard-coded in GCC
> default specs.
> [20:58:48] <lh_mouse> I only found `-ladvapi32 -lshell32 -luser32
> -lkernel32`. The list ends there.
> [20:59:11] <lh_mouse> not sure how those additional libraries were added.
> [21:00:04] <wbs> lld is nice in this aspect, that it doesn't need static
> libraries ordered like this; for each undefined, it searches the list of
> static libraries from the start
> [21:01:07] <lh_mouse> LD is dumb. :(
> [21:02:53] <lh_mouse> I thought MSVCRT was only an import library. It
> seems more complicated.
> [21:04:18] <wbs> it has (almost) always been more than that - there's
> been some stub functions that call GetProcAddress() and try to
> conditionally load functions if available
> [21:04:53] <wbs> and especially with ucrt, we want to move quite a bit
> of things from libmingwex.a to libmsvcrt-os.a, for things where we can
> and should use the ucrt equivalent instead of statically linking in our own
> [21:05:32] <lh_mouse> GetProcAdress() requires a successive -lkernel32 too.
> [21:05:45] <wbs> indeed
> [21:06:56] <lh_mouse> so this suddenly becomes a GCC issue in its
> default specs: `-lkernel32` is required after `-lmsvcrt`.
> [21:07:33] <wbs> yes, pretty much. clang has got the same structure as well
> [21:07:44] <wbs> (which matters for cases when using clang on top of ld.bfd)
> [21:08:48] <wbs> looks like it's REAL_LIBGCC_SPEC in
> gcc/config/i386/mingw32.h that needs to be updated
> ```
>
>
> Thanks pushed to master.
signature.asc
Description: OpenPGP digital signature
