[PATCH] Ensure `-lmsvcrt` precede `-lkernel32`

[PATCH] Ensure `-lmsvcrt` precede `-lkernel32`

[Liu Hao]

[-- Attachment #1.1: Type: text/plain, Size: 811 bytes --]

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} \
-- 
2.26.2



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Ensure `-lmsvcrt` precede `-lkernel32`

[Liu Hao]

[-- Attachment #1.1: Type: text/plain, Size: 4990 bytes --]

在 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 (~tchan@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
```



-- 
Best regards,
LH_Mouse


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Ensure `-lmsvcrt` precede `-lkernel32`

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 5210 bytes --]

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 (~tchan@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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]