* Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 12:53 gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library Pali Rohár
@ 2022-11-20 13:36 ` LIU Hao
2022-11-20 15:06 ` Pali Rohár
2022-11-20 14:45 ` Eli Zaretskii
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: LIU Hao @ 2022-11-20 13:36 UTC (permalink / raw)
To: mingw-w64-public, Pali Rohár, gcc
[-- Attachment #1.1: Type: text/plain, Size: 1369 bytes --]
在 2022-11-20 20:53, Pali Rohár 写道:
> Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> allow specifying against which Windows C Runtime library should be
> binary linked. On Windows there are more crt libraries and currently gcc
> links to libmsvcrt.a which is in most cases symlink to libmsvcrt-os.a
> (but can be changed, e.g. during mingw-w64 building). mingw-w64 project
> already builds import .a library for every crt dll library (from the old
> crtdll.dll up to the new ucrtbase.dll), so it is ready for usage. Simple
> patch for gcc which implements -mcrtdll parameter is below. Note that on
> internet are other very similar patches for -mcrtdll= parameters and
> some are parts of custom mingw32 / mingw-w64 gcc builds. What do you
> think? Could gcc have "official" support for -mcrtdll= parameter?
>
>
It's not enough to just link against the desired library, you will also have to define
`__MSVCRT_VERSION__` accordingly (for UCRT it should be defined as `0xE00` i.e. 14.0).
The current status of such mechanism is that both the macro `__MSVCRT_VERSION__` and the library
'libmsvcrt.a' are determined when building mingw-w64, configurable by `--with-default-msvcrt=`, so
they always match.
[1] https://sourceforge.net/p/mingw-w64/mailman/message/36030072/
--
Best regards,
LIU Hao
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 13:36 ` [Mingw-w64-public] " LIU Hao
@ 2022-11-20 15:06 ` Pali Rohár
2022-11-21 5:21 ` LIU Hao
0 siblings, 1 reply; 19+ messages in thread
From: Pali Rohár @ 2022-11-20 15:06 UTC (permalink / raw)
To: LIU Hao; +Cc: mingw-w64-public, gcc
On Sunday 20 November 2022 21:36:19 LIU Hao wrote:
> 在 2022-11-20 20:53, Pali Rohár 写道:
> > Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> > allow specifying against which Windows C Runtime library should be
> > binary linked. On Windows there are more crt libraries and currently gcc
> > links to libmsvcrt.a which is in most cases symlink to libmsvcrt-os.a
> > (but can be changed, e.g. during mingw-w64 building). mingw-w64 project
> > already builds import .a library for every crt dll library (from the old
> > crtdll.dll up to the new ucrtbase.dll), so it is ready for usage. Simple
> > patch for gcc which implements -mcrtdll parameter is below. Note that on
> > internet are other very similar patches for -mcrtdll= parameters and
> > some are parts of custom mingw32 / mingw-w64 gcc builds. What do you
> > think? Could gcc have "official" support for -mcrtdll= parameter?
> >
> >
>
> It's not enough to just link against the desired library, you will also have
> to define `__MSVCRT_VERSION__` accordingly (for UCRT it should be defined as
> `0xE00` i.e. 14.0).
>
> The current status of such mechanism is that both the macro
> `__MSVCRT_VERSION__` and the library 'libmsvcrt.a' are determined when
> building mingw-w64, configurable by `--with-default-msvcrt=`, so they always
> match.
>
>
> [1] https://sourceforge.net/p/mingw-w64/mailman/message/36030072/
Thank you for explaining more details. My simple patch takes this in
care and defines also __MSVCRT_VERSION__ to the correct value based on
-mcrtdll parameter.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 15:06 ` Pali Rohár
@ 2022-11-21 5:21 ` LIU Hao
2022-11-26 19:09 ` Pali Rohár
0 siblings, 1 reply; 19+ messages in thread
From: LIU Hao @ 2022-11-21 5:21 UTC (permalink / raw)
To: Pali Rohár; +Cc: mingw-w64-public, gcc
[-- Attachment #1.1: Type: text/plain, Size: 1287 bytes --]
在 2022/11/20 23:06, Pali Rohár 写道:
> Thank you for explaining more details. My simple patch takes this in
> care and defines also __MSVCRT_VERSION__ to the correct value based on
> -mcrtdll parameter.
Apologies for reading your message only partially. I thought your patch was the same as MSYS2's. It
turns out that you have made further progress; that's very kind of you.
As for the patch itself: It's probably safe to switch between MSVCR* DLLs, but switching from MSVCR*
to UCRT requires a complete rebuild due to differences in implementation of stdio functions and
definition of `time_t` on x86. There are more reasons, for example, that MSVCR80 and 90 require
architecture-specific manifests to load, and MSVCR80 to 120 are not pre-installed and have to be
installed by users. These could explain why `-mcrtdll=` hasn't gained wide use, while UCRT-based
toolchains have.
So, the patch may be acceptable, but I don't think it will solve the issue for you. A user should
usually choose MSVCRT or UCRT, which however requires rebuilding the CRT. For those who really
really wish to link against MSVCR100 for example, it's always doable to pass `-nodefaultlibs` to
GCC, and specify desired libraries explicitly.
--
Best regards,
LIU Hao
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-21 5:21 ` LIU Hao
@ 2022-11-26 19:09 ` Pali Rohár
2022-11-27 1:06 ` sotrdg sotrdg
0 siblings, 1 reply; 19+ messages in thread
From: Pali Rohár @ 2022-11-26 19:09 UTC (permalink / raw)
To: LIU Hao; +Cc: mingw-w64-public, gcc
On Monday 21 November 2022 13:21:53 LIU Hao wrote:
> 在 2022/11/20 23:06, Pali Rohár 写道:
> > Thank you for explaining more details. My simple patch takes this in
> > care and defines also __MSVCRT_VERSION__ to the correct value based on
> > -mcrtdll parameter.
>
> Apologies for reading your message only partially. I thought your patch was
> the same as MSYS2's. It turns out that you have made further progress;
> that's very kind of you.
>
> As for the patch itself: It's probably safe to switch between MSVCR* DLLs,
> but switching from MSVCR* to UCRT requires a complete rebuild due to
> differences in implementation of stdio functions and definition of `time_t`
> on x86. There are more reasons, for example, that MSVCR80 and 90 require
> architecture-specific manifests to load, and MSVCR80 to 120 are not
> pre-installed and have to be installed by users. These could explain why
> `-mcrtdll=` hasn't gained wide use, while UCRT-based toolchains have.
>
> So, the patch may be acceptable, but I don't think it will solve the issue
> for you. A user should usually choose MSVCRT or UCRT, which however requires
> rebuilding the CRT. For those who really really wish to link against
> MSVCR100 for example, it's always doable to pass `-nodefaultlibs` to GCC,
> and specify desired libraries explicitly.
The ultimate goal could be to improve mingw-w64 build process to compile
one set of libraries which would work with both msvcrt and ucrt. There
is already discussion about it in separate mingw-w64 email thread.
Probably not easy task, but I think it can be possible. Anyway, in any
case, this work is independent of gcc and independent of introduction of
-mcrtdll= gcc switch. So I think this switch still can be useful.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-26 19:09 ` Pali Rohár
@ 2022-11-27 1:06 ` sotrdg sotrdg
0 siblings, 0 replies; 19+ messages in thread
From: sotrdg sotrdg @ 2022-11-27 1:06 UTC (permalink / raw)
To: mingw-w64-public, LIU Hao; +Cc: gcc, mingw-w64-public
[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]
what you want is basically a ucrt multilib. However, neither glibc provides the same toggle too. i do not see a good reason for your request.
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Pali Rohár <pali.rohar@gmail.com>
Sent: Saturday, November 26, 2022 2:09:09 PM
To: LIU Hao <lh_mouse@126.com>
Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>; mingw-w64-public@lists.sourceforge.net <mingw-w64-public@lists.sourceforge.net>
Subject: Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
On Monday 21 November 2022 13:21:53 LIU Hao wrote:
> 在 2022/11/20 23:06, Pali Rohár 写道:
> > Thank you for explaining more details. My simple patch takes this in
> > care and defines also __MSVCRT_VERSION__ to the correct value based on
> > -mcrtdll parameter.
>
> Apologies for reading your message only partially. I thought your patch was
> the same as MSYS2's. It turns out that you have made further progress;
> that's very kind of you.
>
> As for the patch itself: It's probably safe to switch between MSVCR* DLLs,
> but switching from MSVCR* to UCRT requires a complete rebuild due to
> differences in implementation of stdio functions and definition of `time_t`
> on x86. There are more reasons, for example, that MSVCR80 and 90 require
> architecture-specific manifests to load, and MSVCR80 to 120 are not
> pre-installed and have to be installed by users. These could explain why
> `-mcrtdll=` hasn't gained wide use, while UCRT-based toolchains have.
>
> So, the patch may be acceptable, but I don't think it will solve the issue
> for you. A user should usually choose MSVCRT or UCRT, which however requires
> rebuilding the CRT. For those who really really wish to link against
> MSVCR100 for example, it's always doable to pass `-nodefaultlibs` to GCC,
> and specify desired libraries explicitly.
The ultimate goal could be to improve mingw-w64 build process to compile
one set of libraries which would work with both msvcrt and ucrt. There
is already discussion about it in separate mingw-w64 email thread.
Probably not easy task, but I think it can be possible. Anyway, in any
case, this work is independent of gcc and independent of introduction of
-mcrtdll= gcc switch. So I think this switch still can be useful.
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 12:53 gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library Pali Rohár
2022-11-20 13:36 ` [Mingw-w64-public] " LIU Hao
@ 2022-11-20 14:45 ` Eli Zaretskii
2022-11-20 15:04 ` Pali Rohár
2022-11-20 21:22 ` Martin Storsjö
2022-12-04 12:16 ` Pali Rohár
3 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2022-11-20 14:45 UTC (permalink / raw)
To: Pali Rohár; +Cc: gcc, mingw-w64-public
> Date: Sun, 20 Nov 2022 13:53:48 +0100
> From: Pali Rohár via Gcc <gcc@gcc.gnu.org>
>
> Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> allow specifying against which Windows C Runtime library should be
> binary linked. On Windows there are more crt libraries and currently gcc
> links to libmsvcrt.a which is in most cases symlink to libmsvcrt-os.a
> (but can be changed, e.g. during mingw-w64 building). mingw-w64 project
> already builds import .a library for every crt dll library (from the old
> crtdll.dll up to the new ucrtbase.dll), so it is ready for usage. Simple
> patch for gcc which implements -mcrtdll parameter is below. Note that on
> internet are other very similar patches for -mcrtdll= parameters and
> some are parts of custom mingw32 / mingw-w64 gcc builds. What do you
> think? Could gcc have "official" support for -mcrtdll= parameter?
Linking a program against a specific runtime means the produced binary will
not run on Windows systems older than the one where it was linked. Why is
such a limitation a good idea, may I ask?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 14:45 ` Eli Zaretskii
@ 2022-11-20 15:04 ` Pali Rohár
2022-11-20 15:23 ` Eli Zaretskii
0 siblings, 1 reply; 19+ messages in thread
From: Pali Rohár @ 2022-11-20 15:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gcc, mingw-w64-public
On Sunday 20 November 2022 16:45:55 Eli Zaretskii wrote:
> > Date: Sun, 20 Nov 2022 13:53:48 +0100
> > From: Pali Rohár via Gcc <gcc@gcc.gnu.org>
> >
> > Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> > allow specifying against which Windows C Runtime library should be
> > binary linked. On Windows there are more crt libraries and currently gcc
> > links to libmsvcrt.a which is in most cases symlink to libmsvcrt-os.a
> > (but can be changed, e.g. during mingw-w64 building). mingw-w64 project
> > already builds import .a library for every crt dll library (from the old
> > crtdll.dll up to the new ucrtbase.dll), so it is ready for usage. Simple
> > patch for gcc which implements -mcrtdll parameter is below. Note that on
> > internet are other very similar patches for -mcrtdll= parameters and
> > some are parts of custom mingw32 / mingw-w64 gcc builds. What do you
> > think? Could gcc have "official" support for -mcrtdll= parameter?
>
> Linking a program against a specific runtime means the produced binary will
> not run on Windows systems older than the one where it was linked. Why is
> such a limitation a good idea, may I ask?
It will run also on older Windows system if you install redistributable
runtime library. Which in most cases is already installed because other
programs use it.
And why you want a new version? Because of better C99/C11 support which
is in ucrtbase.dll
Note that with this option, you can also choose older version than the
default one (WinXP msvcrt.dll). So e.g. you can choose msvcrt20.dll or
crtdll.dll for older Windows version.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 15:04 ` Pali Rohár
@ 2022-11-20 15:23 ` Eli Zaretskii
2022-11-20 15:44 ` Pali Rohár
0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2022-11-20 15:23 UTC (permalink / raw)
To: Pali Rohár; +Cc: gcc, mingw-w64-public
> Date: Sun, 20 Nov 2022 16:04:11 +0100
> From: Pali Rohár <pali.rohar@gmail.com>
> Cc: gcc@gcc.gnu.org, mingw-w64-public@lists.sourceforge.net
>
> On Sunday 20 November 2022 16:45:55 Eli Zaretskii wrote:
> > > Date: Sun, 20 Nov 2022 13:53:48 +0100
> > > From: Pali Rohár via Gcc <gcc@gcc.gnu.org>
> > >
> > Linking a program against a specific runtime means the produced binary will
> > not run on Windows systems older than the one where it was linked. Why is
> > such a limitation a good idea, may I ask?
>
> It will run also on older Windows system if you install redistributable
> runtime library. Which in most cases is already installed because other
> programs use it.
Installing a redistributable is a nuisance, and dependence on non-system
libraries might make the program non-free.
> And why you want a new version? Because of better C99/C11 support which
> is in ucrtbase.dll
That comes with a price, though.
> Note that with this option, you can also choose older version than the
> default one (WinXP msvcrt.dll). So e.g. you can choose msvcrt20.dll or
> crtdll.dll for older Windows version.
Using the OS default MSVCRT already gets me that, at zero cost.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 15:23 ` Eli Zaretskii
@ 2022-11-20 15:44 ` Pali Rohár
2022-11-20 15:58 ` Eli Zaretskii
0 siblings, 1 reply; 19+ messages in thread
From: Pali Rohár @ 2022-11-20 15:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gcc, mingw-w64-public
On Sunday 20 November 2022 17:23:15 Eli Zaretskii wrote:
> > Date: Sun, 20 Nov 2022 16:04:11 +0100
> > From: Pali Rohár <pali.rohar@gmail.com>
> > Cc: gcc@gcc.gnu.org, mingw-w64-public@lists.sourceforge.net
> >
> > On Sunday 20 November 2022 16:45:55 Eli Zaretskii wrote:
> > > > Date: Sun, 20 Nov 2022 13:53:48 +0100
> > > > From: Pali Rohár via Gcc <gcc@gcc.gnu.org>
> > > >
> > > Linking a program against a specific runtime means the produced binary will
> > > not run on Windows systems older than the one where it was linked. Why is
> > > such a limitation a good idea, may I ask?
> >
> > It will run also on older Windows system if you install redistributable
> > runtime library. Which in most cases is already installed because other
> > programs use it.
>
> Installing a redistributable is a nuisance, and dependence on non-system
> libraries might make the program non-free.
On new windows versions they may be preinstalled (depends on newness of
windows version). And if your application uses features unavailable in
older (or default) crt versions then this make application code
simplifier. Also redistributable packages are in most cases installed by
Windows update mechanism, which could be marked as system library. But
well, this is more license discussion than development discussion...
> > And why you want a new version? Because of better C99/C11 support which
> > is in ucrtbase.dll
>
> That comes with a price, though.
>
> > Note that with this option, you can also choose older version than the
> > default one (WinXP msvcrt.dll). So e.g. you can choose msvcrt20.dll or
> > crtdll.dll for older Windows version.
>
> Using the OS default MSVCRT already gets me that, at zero cost.
Here "OS default MSVCRT" means Windows XP MSVCRT.DLL.
On older windows versions there is no pre-installed MSVCRT.DLL. There
is MSVCRT20.DLL or CRTDLL.DLL (based on oldness of windows version). So
it is not at zero cost, you have yo either do that nuisance and install
MSVCRT.DLL as you write above or switch to older CRT version which is in
OS preinstalled.
And proposed gcc parameter -mcrtdll could simplify that switch.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 15:44 ` Pali Rohár
@ 2022-11-20 15:58 ` Eli Zaretskii
2022-11-20 16:19 ` [Mingw-w64-public] " ralph engels
2022-11-20 16:20 ` Matthew Brett
0 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2022-11-20 15:58 UTC (permalink / raw)
To: Pali Rohár; +Cc: gcc, mingw-w64-public
> Date: Sun, 20 Nov 2022 16:44:08 +0100
> From: Pali Rohár <pali.rohar@gmail.com>
> Cc: gcc@gcc.gnu.org, mingw-w64-public@lists.sourceforge.net
>
> > Installing a redistributable is a nuisance, and dependence on non-system
> > libraries might make the program non-free.
>
> On new windows versions they may be preinstalled (depends on newness of
> windows version).
I'm talking about older ones. It is customary nowadays to build on Windows
11 and then run on Windows 8.
> And if your application uses features unavailable in
> older (or default) crt versions then this make application code
> simplifier. Also redistributable packages are in most cases installed by
> Windows update mechanism, which could be marked as system library. But
> well, this is more license discussion than development discussion...
I mentioned that because people might inadvertently build GPL'ed GNU
software using this option, and violate the GPL without knowing it. This is
relevant to those who read this list and port GNU software to MS-Windows.
> > > Note that with this option, you can also choose older version than the
> > > default one (WinXP msvcrt.dll). So e.g. you can choose msvcrt20.dll or
> > > crtdll.dll for older Windows version.
> >
> > Using the OS default MSVCRT already gets me that, at zero cost.
>
> Here "OS default MSVCRT" means Windows XP MSVCRT.DLL.
>
> On older windows versions there is no pre-installed MSVCRT.DLL. There
> is MSVCRT20.DLL or CRTDLL.DLL (based on oldness of windows version). So
> it is not at zero cost, you have yo either do that nuisance and install
> MSVCRT.DLL as you write above or switch to older CRT version which is in
> OS preinstalled.
I never saw any problems with programs linked against MSVCRT.DLL, on all
versions of Windows from XP up to Windows 10. None.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 15:58 ` Eli Zaretskii
@ 2022-11-20 16:19 ` ralph engels
2022-11-20 16:20 ` Matthew Brett
1 sibling, 0 replies; 19+ messages in thread
From: ralph engels @ 2022-11-20 16:19 UTC (permalink / raw)
To: mingw-w64-public, Eli Zaretskii, Pali Rohár; +Cc: gcc
Mmm yeah i newer seen problems with missing msvcrt.dll either going back
as far as win9x there was some other missing runtimes but not that
particular one.
Den 20-11-2022 kl. 16:58 skrev Eli Zaretskii:
>> Date: Sun, 20 Nov 2022 16:44:08 +0100
>> From: Pali Rohár <pali.rohar@gmail.com>
>> Cc: gcc@gcc.gnu.org, mingw-w64-public@lists.sourceforge.net
>>
>>> Installing a redistributable is a nuisance, and dependence on non-system
>>> libraries might make the program non-free.
>> On new windows versions they may be preinstalled (depends on newness of
>> windows version).
> I'm talking about older ones. It is customary nowadays to build on Windows
> 11 and then run on Windows 8.
>
>> And if your application uses features unavailable in
>> older (or default) crt versions then this make application code
>> simplifier. Also redistributable packages are in most cases installed by
>> Windows update mechanism, which could be marked as system library. But
>> well, this is more license discussion than development discussion...
> I mentioned that because people might inadvertently build GPL'ed GNU
> software using this option, and violate the GPL without knowing it. This is
> relevant to those who read this list and port GNU software to MS-Windows.
>
>>>> Note that with this option, you can also choose older version than the
>>>> default one (WinXP msvcrt.dll). So e.g. you can choose msvcrt20.dll or
>>>> crtdll.dll for older Windows version.
>>> Using the OS default MSVCRT already gets me that, at zero cost.
>> Here "OS default MSVCRT" means Windows XP MSVCRT.DLL.
>>
>> On older windows versions there is no pre-installed MSVCRT.DLL. There
>> is MSVCRT20.DLL or CRTDLL.DLL (based on oldness of windows version). So
>> it is not at zero cost, you have yo either do that nuisance and install
>> MSVCRT.DLL as you write above or switch to older CRT version which is in
>> OS preinstalled.
> I never saw any problems with programs linked against MSVCRT.DLL, on all
> versions of Windows from XP up to Windows 10. None.
>
>
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 15:58 ` Eli Zaretskii
2022-11-20 16:19 ` [Mingw-w64-public] " ralph engels
@ 2022-11-20 16:20 ` Matthew Brett
1 sibling, 0 replies; 19+ messages in thread
From: Matthew Brett @ 2022-11-20 16:20 UTC (permalink / raw)
To: mingw-w64-public; +Cc: Pali Rohár, gcc
Hi,
On Sun, Nov 20, 2022 at 3:59 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Sun, 20 Nov 2022 16:44:08 +0100
> > From: Pali Rohár <pali.rohar@gmail.com>
> > Cc: gcc@gcc.gnu.org, mingw-w64-public@lists.sourceforge.net
> >
> > > Installing a redistributable is a nuisance, and dependence on non-system
> > > libraries might make the program non-free.
> >
> > On new windows versions they may be preinstalled (depends on newness of
> > windows version).
>
> I'm talking about older ones. It is customary nowadays to build on Windows
> 11 and then run on Windows 8.
>
> > And if your application uses features unavailable in
> > older (or default) crt versions then this make application code
> > simplifier. Also redistributable packages are in most cases installed by
> > Windows update mechanism, which could be marked as system library. But
> > well, this is more license discussion than development discussion...
>
> I mentioned that because people might inadvertently build GPL'ed GNU
> software using this option, and violate the GPL without knowing it. This is
> relevant to those who read this list and port GNU software to MS-Windows.
>
> > > > Note that with this option, you can also choose older version than the
> > > > default one (WinXP msvcrt.dll). So e.g. you can choose msvcrt20.dll or
> > > > crtdll.dll for older Windows version.
> > >
> > > Using the OS default MSVCRT already gets me that, at zero cost.
> >
> > Here "OS default MSVCRT" means Windows XP MSVCRT.DLL.
> >
> > On older windows versions there is no pre-installed MSVCRT.DLL. There
> > is MSVCRT20.DLL or CRTDLL.DLL (based on oldness of windows version). So
> > it is not at zero cost, you have yo either do that nuisance and install
> > MSVCRT.DLL as you write above or switch to older CRT version which is in
> > OS preinstalled.
>
> I never saw any problems with programs linked against MSVCRT.DLL, on all
> versions of Windows from XP up to Windows 10. None.
It's hard to argue that it is rarely necessary or desirable to link to
- say - UCRT. If it was, then we would not have the UCRT toolchains.
And in our particular case (Python extension modules) we need to use
UCRT linking to be compatible with the UCRT-linked standard Python
binary installs.
Cheers,
Matthew
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 12:53 gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library Pali Rohár
2022-11-20 13:36 ` [Mingw-w64-public] " LIU Hao
2022-11-20 14:45 ` Eli Zaretskii
@ 2022-11-20 21:22 ` Martin Storsjö
2022-12-04 12:16 ` Pali Rohár
3 siblings, 0 replies; 19+ messages in thread
From: Martin Storsjö @ 2022-11-20 21:22 UTC (permalink / raw)
To: mingw-w64-public; +Cc: gcc
[-- Attachment #1: Type: text/plain, Size: 3207 bytes --]
On Sun, 20 Nov 2022, Pali Rohár wrote:
> Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> allow specifying against which Windows C Runtime library should be
> binary linked. On Windows there are more crt libraries and currently gcc
> links to libmsvcrt.a which is in most cases symlink to libmsvcrt-os.a
> (but can be changed, e.g. during mingw-w64 building). mingw-w64 project
> already builds import .a library for every crt dll library (from the old
> crtdll.dll up to the new ucrtbase.dll), so it is ready for usage. Simple
> patch for gcc which implements -mcrtdll parameter is below. Note that on
> internet are other very similar patches for -mcrtdll= parameters and
> some are parts of custom mingw32 / mingw-w64 gcc builds. What do you
> think? Could gcc have "official" support for -mcrtdll= parameter?
I think it would be important to add as context here:
The fact that you can use a different CRT DLL isn't controversial here -
mingw-w64 has had that option since 2017. As LIU Hao pointed out, the
common way of doing that is by configuring the default with
--with-default-msvcrt= in mingw-w64-headers and mingw-w64-crt.
The reason for this, is that the only entirely robust way of switching
from one CRT to another (especially between the msvcr* and UCRT) is by
rebuilding the toolchain (including all toolchain bundled runtime
libraries such as libgcc and libstdc++) from scratch with the desired
default, since there are some subtle ABI differences at various points.
Earlier, there were bigger differences (e.g. for UCRT, most stdio
functions were defined inline in headers, expanding to calls to e.g.
__stdio_common_vfprintf), while things have been unified a bit more.
For most C executables, switching to a non-default CRT probably is safe as
long as all user code is compiled with the right, consistent
__MSVCRT_VERSION__/_UCRT defines, and runtime libraries (libgcc or
compiler-rt builtins) are linked statically.
For C++ code, I'm fairly sure that both libstdc++ and libc++ contain
references to things that differ between msvcr* and UCRT.
While some differences between the CRT choices have vanished (moved into
the CRT import libraries), there are some remaining differences that
fundamentally are hard to get rid of.
With Clang/LLD, it's possible to manually experiment with linking a
different CRT - you need to manually set the right -D__MSVCRT_VERSION__ /
-D_UCRT, and manually pass -lmsvcr* or -lucrt; whenever an option that
matches -lmsvcr*, -lucrt* or -lcrtdll is detected, Clang omits the default
-lmsvcrt.
I don't oppose adding an option like this to GCC (and having such an
option does help experimenting with reducing the differences) - but it
does need to come with a pretty stern disclaimer, warning the user that
they're pretty much on their own if they use it, and that it only really
fully works as desired under some specific circumstances.
As a technical detail to the patch, you could add ucrtbase as a separate
alternative to ucrt too. With the ucrtbase import library, the executable
links directly against the ucrtbase.dll library instead of using the
api-ms-win-crt-* frontend libraries.
// Martin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-11-20 12:53 gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library Pali Rohár
` (2 preceding siblings ...)
2022-11-20 21:22 ` Martin Storsjö
@ 2022-12-04 12:16 ` Pali Rohár
2022-12-04 12:48 ` LIU Hao
3 siblings, 1 reply; 19+ messages in thread
From: Pali Rohár @ 2022-12-04 12:16 UTC (permalink / raw)
To: gcc; +Cc: mingw-w64-public
On Sunday 20 November 2022 13:53:48 Pali Rohár wrote:
> Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> allow specifying against which Windows C Runtime library should be
> binary linked. On Windows there are more crt libraries and currently gcc
> links to libmsvcrt.a which is in most cases symlink to libmsvcrt-os.a
> (but can be changed, e.g. during mingw-w64 building). mingw-w64 project
> already builds import .a library for every crt dll library (from the old
> crtdll.dll up to the new ucrtbase.dll), so it is ready for usage. Simple
> patch for gcc which implements -mcrtdll parameter is below. Note that on
> internet are other very similar patches for -mcrtdll= parameters and
> some are parts of custom mingw32 / mingw-w64 gcc builds. What do you
> think? Could gcc have "official" support for -mcrtdll= parameter?
Hello! I would like to ask gcc people, what do you think about such
proposed -mcrtdll= parameter?
There are lot of unofficial gcc patches which implement this -mcrtdll=
parameter and this parameter is present in more gcc forks.
So it looks like that this parameter is useful for more people.
Here is list of some URLs which I found:
https://sourceforge.net/p/mingw/mailman/message/5692227/
https://sourceforge.net/p/mingw-w64/mailman/message/36030107/
https://github.com/jmeubank/tdm-gcc-src/blob/tdm-patches.public/_PATCHES/mcrtdll.patch
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0006-Windows-New-feature-to-allow-overriding.patch
https://github.com/nak5124/build_env/blob/master/gcc_build/patches/gcc/0020-MinGW-w64-Define-__MSVCRT_VERSION__.patch
But I have not found any discussion about it on gcc mailing list.
>
> --- gcc/config/i386/cygming.opt 2022-02-06 21:00:05.377656896 +0100
> +++ gcc/config/i386/cygming.opt 2022-02-06 21:04:06.690995944 +0100
> @@ -22,6 +22,10 @@ mconsole
> Target RejectNegative
> Create console application.
>
> +mcrtdll=
> +Target RejectNegative Joined
> +Link with specified C RunTime DLL library.
> +
> mdll
> Target RejectNegative
> Generate code for a DLL.
> --- gcc/config/i386/mingw32.h 2022-01-16 17:28:31.157999097 +0100
> +++ gcc/config/i386/mingw32.h 2022-01-16 17:36:03.552856726 +0100
> @@ -95,7 +95,20 @@ along with GCC; see the file COPYING3.
> #undef CPP_SPEC
> #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} " \
> "%{" SPEC_PTHREAD1 ":-D_REENTRANT} " \
> - "%{" SPEC_PTHREAD2 ": } "
> + "%{" SPEC_PTHREAD2 ": } " \
> + "%{mcrtdll=crtdll*:-U__MSVCRT__ -D__CRTDLL__} " \
> + "%{mcrtdll=msvcrt10*:-D__MSVCRT_VERSION__=0x100} " \
> + "%{mcrtdll=msvcrt20*:-D__MSVCRT_VERSION__=0x200} " \
> + "%{mcrtdll=msvcrt40*:-D__MSVCRT_VERSION__=0x400} " \
> + "%{mcrtdll=msvcrt-os*:-D__MSVCRT_VERSION__=0x700} " \
> + "%{mcrtdll=msvcr70*:-D__MSVCRT_VERSION__=0x700} " \
> + "%{mcrtdll=msvcr71*:-D__MSVCRT_VERSION__=0x701} " \
> + "%{mcrtdll=msvcr80*:-D__MSVCRT_VERSION__=0x800} " \
> + "%{mcrtdll=msvcr90*:-D__MSVCRT_VERSION__=0x900} " \
> + "%{mcrtdll=msvcr100*:-D__MSVCRT_VERSION__=0xA00} " \
> + "%{mcrtdll=msvcr110*:-D__MSVCRT_VERSION__=0xB00} " \
> + "%{mcrtdll=msvcr120*:-D__MSVCRT_VERSION__=0xC00} " \
> + "%{mcrtdll=ucrt*:-D_UCRT} "
>
> /* For Windows applications, include more libraries, but always include
> kernel32. */
> @@ -185,11 +198,16 @@ along with GCC; see the file COPYING3.
> #define REAL_LIBGCC_SPEC \
> "%{mthreads:-lmingwthrd} -lmingw32 \
> " SHARED_LIBGCC_SPEC " \
> - -lmoldname -lmingwex -lmsvcrt -lkernel32"
> + -lmoldname -lmingwex %{!mcrtdll=*:-lmsvcrt} %{mcrtdll=*:-l%*} -lkernel32"
>
> #undef STARTFILE_SPEC
> -#define STARTFILE_SPEC "%{shared|mdll:dllcrt2%O%s} \
> - %{!shared:%{!mdll:crt2%O%s}} %{pg:gcrt2%O%s} \
> +#define STARTFILE_SPEC " \
> + %{shared|mdll:%{mcrtdll=crtdll*:dllcrt1%O%s}} \
> + %{shared|mdll:%{!mcrtdll=crtdll*:dllcrt2%O%s}} \
> + %{!shared:%{!mdll:%{mcrtdll=crtdll*:crt1%O%s}}} \
> + %{!shared:%{!mdll:%{!mcrtdll=crtdll*:crt2%O%s}}} \
> + %{pg:%{mcrtdll=crtdll*:gcrt1%O%s}} \
> + %{pg:%{!mcrtdll=crtdll*:gcrt2%O%s}} \
> crtbegin.o%s \
> %{fvtable-verify=none:%s; \
> fvtable-verify=preinit:vtv_start.o%s; \
>
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-12-04 12:16 ` Pali Rohár
@ 2022-12-04 12:48 ` LIU Hao
2023-04-21 16:23 ` Pali Rohár
0 siblings, 1 reply; 19+ messages in thread
From: LIU Hao @ 2022-12-04 12:48 UTC (permalink / raw)
To: Pali Rohár, gcc; +Cc: mingw-w64-public
[-- Attachment #1.1: Type: text/plain, Size: 524 bytes --]
在 2022-12-04 20:16, Pali Rohár via Gcc 写道:
> Hello! I would like to ask gcc people, what do you think about such
> proposed -mcrtdll= parameter?
>
> There are lot of unofficial gcc patches which implement this -mcrtdll=
> parameter and this parameter is present in more gcc forks.
> So it looks like that this parameter is useful for more people.
>
I vote +1 for this in GCC 14.
GCC 13 (i.e. current master branch) is at stage3 so it's not an option at this moment.
--
Best regards,
LIU Hao
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2022-12-04 12:48 ` LIU Hao
@ 2023-04-21 16:23 ` Pali Rohár
2023-05-06 10:45 ` Pali Rohár
0 siblings, 1 reply; 19+ messages in thread
From: Pali Rohár @ 2023-04-21 16:23 UTC (permalink / raw)
To: LIU Hao; +Cc: gcc, mingw-w64-public
On Sunday 04 December 2022 20:48:30 LIU Hao wrote:
> 在 2022-12-04 20:16, Pali Rohár via Gcc 写道:
> > Hello! I would like to ask gcc people, what do you think about such
> > proposed -mcrtdll= parameter?
> >
> > There are lot of unofficial gcc patches which implement this -mcrtdll=
> > parameter and this parameter is present in more gcc forks.
> > So it looks like that this parameter is useful for more people.
> >
>
> I vote +1 for this in GCC 14.
>
> GCC 13 (i.e. current master branch) is at stage3 so it's not an option at this moment.
>
>
> --
> Best regards,
> LIU Hao
>
Hello! If I'm looking correctly, gcc 13 was already branched. So what
revisiting this -mcrtdll= parameter now?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2023-04-21 16:23 ` Pali Rohár
@ 2023-05-06 10:45 ` Pali Rohár
2023-05-08 3:44 ` LIU Hao
0 siblings, 1 reply; 19+ messages in thread
From: Pali Rohár @ 2023-05-06 10:45 UTC (permalink / raw)
To: gcc; +Cc: mingw-w64-public, LIU Hao
On Friday 21 April 2023 18:23:28 Pali Rohár wrote:
> On Sunday 04 December 2022 20:48:30 LIU Hao wrote:
> > 在 2022-12-04 20:16, Pali Rohár via Gcc 写道:
> > > Hello! I would like to ask gcc people, what do you think about such
> > > proposed -mcrtdll= parameter?
> > >
> > > There are lot of unofficial gcc patches which implement this -mcrtdll=
> > > parameter and this parameter is present in more gcc forks.
> > > So it looks like that this parameter is useful for more people.
> > >
> >
> > I vote +1 for this in GCC 14.
> >
> > GCC 13 (i.e. current master branch) is at stage3 so it's not an option at this moment.
> >
> >
> > --
> > Best regards,
> > LIU Hao
> >
>
> Hello! If I'm looking correctly, gcc 13 was already branched. So what
> revisiting this -mcrtdll= parameter now?
Hello! I would like to remind this -mcrtdll= support for gcc.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
2023-05-06 10:45 ` Pali Rohár
@ 2023-05-08 3:44 ` LIU Hao
0 siblings, 0 replies; 19+ messages in thread
From: LIU Hao @ 2023-05-08 3:44 UTC (permalink / raw)
To: Pali Rohár, gcc; +Cc: mingw-w64-public
[-- Attachment #1.1: Type: text/plain, Size: 777 bytes --]
在 2023/5/6 18:45, Pali Rohár 写道:
>> Hello! If I'm looking correctly, gcc 13 was already branched. So what
>> revisiting this -mcrtdll= parameter now?
>
> Hello! I would like to remind this -mcrtdll= support for gcc.
As said before, the idea sounds good. But in order for your patch to be checked in, you need to
1) Sign off your commit.
2) Append ChangeLog entries to the commit message. You may take other commits
as references. They are required for all directories with a ChangeLog file,
and will be parsed by server-side Git hook scripts.
3) Send this patch to gcc-patches@gcc.gnu.org with a CC to Jonathan Yong
<10walls@gmail.com>, who is the only maintainer on GCC for mingw-w64 port.
--
Best regards,
LIU Hao
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread