Ensure `-lmsvcrt` precede `-lkernel32`

Message ID 8d3d3d76-53dc-8efe-2d7b-2876b5527ac7@126.com
State New
Headers show
Series
  • Ensure `-lmsvcrt` precede `-lkernel32`
Related show

Commit Message

Jakub Jelinek via Gcc-patches May 29, 2020, 2:01 p.m.
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(-)

Comments

Jakub Jelinek via Gcc-patches May 29, 2020, 2:04 p.m. | #1
在 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
Jakub Jelinek via Gcc-patches May 30, 2020, 4:56 a.m. | #2
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.

Patch

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