GCC 13 bootstrap failure on i686-w64-mingw32
This is caused by 2efb237ffc68ec9bb17982434f5941bfa14f8b50, which has references to `strchrnul`, which does not exist on i686w-64-mingw32: ``` g++ -std=c++11 -fno-PIE -c -DIN_GCC_FRONTEND -g -D__USE_MINGW_ACCESS -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Icp -I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody -I/mingw32/include -I/mingw32/include -I/mingw32/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/gcc/../libbacktrace -I/mingw32/include -D__USE_MINGW_ANSI_STDIO=1 -I/mingw32/include -o cp/error.o -MT cp/error.o -MMD -MP -MF cp/.deps/error.TPo ../../gcc/gcc/cp/error.cc ../../gcc/gcc/cp/contracts.cc: In function 'bool role_name_equal(const char*, const char*)': ../../gcc/gcc/cp/contracts.cc:213:21: error: 'strchrnul' was not declared in this scope; did you mean 'strchr'? 213 | size_t role_len = strchrnul (role, ':') - role; | ^ | strchr make[3]: *** [Makefile:1146: cp/contracts.o] Error 1 make[3]: *** Waiting for unfinished jobs ``` Proposed solution: ``` size_t role_len = strcspn (role, ":"); ``` -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature
gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
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?
--- 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; \
Re: Problems when building NT kernel drivers with GCC / LD
On Saturday 05 November 2022 02:26:52 Pali Rohár wrote: > On Saturday 05 November 2022 01:57:49 Pali Rohár wrote: > > On Monday 31 October 2022 10:55:59 Jan Beulich wrote: > > > On 30.10.2022 02:06, Pali Rohár via Binutils wrote: > > > > * GCC or LD (not sure who) sets memory alignment characteristics > > > > (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary. > > > > These characteristics should be only in COFF object files, not > > > > executable binaries. Specially they should not be in NT kernel > > > > drivers. > > > > > > Like Martin pointed out in reply for another item, I'm pretty sure > > > this one was taken care of in bfd already (and iirc is in 2.39). You > > > fail to mention at all what versions of the various components you > > > use. > > > > Ou, sorry for that. I take care to write issues in all details and > > totally forgot to write such important information like tool versions. > > > > Now I retested all issues on Debian 11 which has LD 2.35.2 and GCC > > 10.2.1 and all issues are there still valid except data characteristic > > IMAGE_SCN_CNT_INITIALIZED_DATA for code sections IMAGE_SCN_CNT_CODE. > > > > I can easily retest it with LD 2.39 and GCC 10.3.0 which is in Debian > > testing. > > Retested with LD 2.39 and GCC 10.3.0 which is in Debian testing and > following problems are additionally fixed: --exclude-all-symbols, > --dynamicbase and IMAGE_SCN_ALIGN_MASK (which you mentioned above). All > other still reminds. > > Do you need some other information? Hello! I would like to ask if you need some other details or something else for these issues. > > > I guess before reporting such a long list of issue you would > > > have wanted to test at least with the most recent releases of each > > > of the involved components. I wouldn't exclude some further items > > > could then be scratched off your list. > > > > > > Jan
Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
在 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 OpenPGP_signature Description: OpenPGP digital signature
Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
> Date: Sun, 20 Nov 2022 13:53:48 +0100 > From: Pali Rohár via Gcc > > 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?
Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
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 > > > > 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.
Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
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.
Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
> Date: Sun, 20 Nov 2022 16:04:11 +0100 > From: Pali Rohár > Cc: gcc@gcc.gnu.org, mingw-w64-pub...@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 > > > > > 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.
Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
On Sunday 20 November 2022 17:23:15 Eli Zaretskii wrote: > > Date: Sun, 20 Nov 2022 16:04:11 +0100 > > From: Pali Rohár > > Cc: gcc@gcc.gnu.org, mingw-w64-pub...@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 > > > > > > > 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.
Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
> Date: Sun, 20 Nov 2022 16:44:08 +0100 > From: Pali Rohár > Cc: gcc@gcc.gnu.org, mingw-w64-pub...@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.
Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
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 Cc: gcc@gcc.gnu.org, mingw-w64-pub...@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-pub...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
Hi, On Sun, Nov 20, 2022 at 3:59 PM Eli Zaretskii wrote: > > > Date: Sun, 20 Nov 2022 16:44:08 +0100 > > From: Pali Rohár > > Cc: gcc@gcc.gnu.org, mingw-w64-pub...@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
Re: GCC 13 bootstrap failure on i686-w64-mingw32
This fails on macOS too (and probably everything non-gnu). On Sun, 20 Nov 2022, 12:36 LIU Hao via Gcc, wrote: > This is caused by 2efb237ffc68ec9bb17982434f5941bfa14f8b50, which has > references to `strchrnul`, > which does not exist on i686w-64-mingw32: > >``` >g++ -std=c++11 -fno-PIE -c -DIN_GCC_FRONTEND -g -D__USE_MINGW_ACCESS > -DIN_GCC > -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall > -Wno-narrowing -Wwrite-strings > -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual > -pedantic -Wno-long-long > -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Icp > -I../../gcc/gcc > -I../../gcc/gcc/cp -I../../gcc/gcc/../include > -I../../gcc/gcc/../libcpp/include > -I../../gcc/gcc/../libcody -I/mingw32/include -I/mingw32/include > -I/mingw32/include > -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid > -I../libdecnumber > -I../../gcc/gcc/../libbacktrace -I/mingw32/include > -D__USE_MINGW_ANSI_STDIO=1 -I/mingw32/include -o > cp/error.o -MT cp/error.o -MMD -MP -MF cp/.deps/error.TPo > ../../gcc/gcc/cp/error.cc >../../gcc/gcc/cp/contracts.cc: In function 'bool role_name_equal(const > char*, const char*)': >../../gcc/gcc/cp/contracts.cc:213:21: error: 'strchrnul' was not > declared in this scope; did you > mean 'strchr'? > 213 | size_t role_len = strchrnul (role, ':') - role; > | ^ > | strchr >make[3]: *** [Makefile:1146: cp/contracts.o] Error 1 >make[3]: *** Waiting for unfinished jobs >``` > > > Proposed solution: > >``` >size_t role_len = strcspn (role, ":"); >``` > > > > -- > Best regards, > LIU Hao >
Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
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
gcc-13-20221120 is now available
Snapshot gcc-13-20221120 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20221120/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision a16a5460447eaaff0b4468064e4d7b1cc8fc42eb You'll find: gcc-13-20221120.tar.xz Complete GCC SHA256=f0f7d7494c8eefdab387fce2a51536d87ed19c466c96ec034ca7645e33f7bf94 SHA1=ac286aaad96e7faed1f39a37df8047062f01dbd2 Diffs from 13-20221113 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
在 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 OpenPGP_signature Description: OpenPGP digital signature
Re: Problems when building NT kernel drivers with GCC / LD
On 20.11.2022 14:10, Pali Rohár wrote: > On Saturday 05 November 2022 02:26:52 Pali Rohár wrote: >> On Saturday 05 November 2022 01:57:49 Pali Rohár wrote: >>> On Monday 31 October 2022 10:55:59 Jan Beulich wrote: On 30.10.2022 02:06, Pali Rohár via Binutils wrote: > * GCC or LD (not sure who) sets memory alignment characteristics > (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary. > These characteristics should be only in COFF object files, not > executable binaries. Specially they should not be in NT kernel > drivers. Like Martin pointed out in reply for another item, I'm pretty sure this one was taken care of in bfd already (and iirc is in 2.39). You fail to mention at all what versions of the various components you use. >>> >>> Ou, sorry for that. I take care to write issues in all details and >>> totally forgot to write such important information like tool versions. >>> >>> Now I retested all issues on Debian 11 which has LD 2.35.2 and GCC >>> 10.2.1 and all issues are there still valid except data characteristic >>> IMAGE_SCN_CNT_INITIALIZED_DATA for code sections IMAGE_SCN_CNT_CODE. >>> >>> I can easily retest it with LD 2.39 and GCC 10.3.0 which is in Debian >>> testing. >> >> Retested with LD 2.39 and GCC 10.3.0 which is in Debian testing and >> following problems are additionally fixed: --exclude-all-symbols, >> --dynamicbase and IMAGE_SCN_ALIGN_MASK (which you mentioned above). All >> other still reminds. >> >> Do you need some other information? > > Hello! I would like to ask if you need some other details or something > else for these issues. Well, generally speaking it might help if you could provide smallish testcases for every item individually. But then, with you replying to me specifically, perhaps you're wrongly assuming that I would be planning to look into addressing any or all of these? My earlier reply was merely to point out that _some_ work has already been done ... Jan
