From dd963fa392d8f9e4ec11d71b3cd2014e45b7e73f Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Feb 03 2023 11:06:30 +0000 Subject: [PATCH 1/10] mingw: remove reference to early state in Fedora 17 What was present in Fedora 17 for mingw is not relevant information for people reading mingw packaging guidelines 20 releases later. Signed-off-by: Daniel P. Berrangé --- diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc index cc5fbb3..746faa4 100644 --- a/guidelines/modules/ROOT/pages/MinGW.adoc +++ b/guidelines/modules/ROOT/pages/MinGW.adoc @@ -4,7 +4,7 @@ The Fedora MinGW project's mission is to provide an excellent development environment for Fedora users who wish to cross-compile their programs to run on Windows, minimizing the need to use Windows at all. In the past developers have had to port and compile all of the libraries and tools they have needed, and this huge effort has happened independently many times over. We aim to eliminate duplication of work for application developers by providing a range of libraries and development tools which have already been ported to the MinGW cross-compiler environment. This means that developers will not need to recompile the application stack themselves, but can concentrate just on the changes needed to their own application. -As of Fedora 17 a set of RPM macros and packages have been introduced which help packagers compile binaries for multiple targets. The targets Win32 and Win64 are supported. +The targets Win32 and Win64 are supported. == Track Fedora native package versions From 3dfbbaf6064ccd420dcc22309fe5f9c3202a3dbe Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Feb 03 2023 11:06:30 +0000 Subject: [PATCH 2/10] mingw: remove reference to secret package comparison script The guidelines reference a script for comparing native and mingw RPMs, however, there is no pointer to where it is. This script has existed as an attachment in a mailing list thread a great many years ago, but was never formalized into something that MinGW maintainers are expected to use. Remove the reference to it so maintainers don't go looking for something they will struggle to find. Signed-off-by: Daniel P. Berrangé --- diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc index 746faa4..82670ce 100644 --- a/guidelines/modules/ROOT/pages/MinGW.adoc +++ b/guidelines/modules/ROOT/pages/MinGW.adoc @@ -11,8 +11,6 @@ The targets Win32 and Win64 are supported. In general terms, cross-compiled MinGW versions of packages which are already natively available in Fedora, should follow the native Fedora package as closely as possible. This means they should stay at the same version, include all the same patches as the native Fedora package, and be built with the same configuration options. -The MinGW SIG have written an RPM comparison tool which makes it possible to compare cross compiled MinGW packages with the Fedora native packages, in order to determine whether versions, patches and configuration are aligned. - == Follow Fedora policy Cross compiled MinGW packages must follow Fedora policy, except where noted in this document. Cross compiled packages go through the same review process, GIT admin process etc. as other Fedora packages. From be5bafa6b72c9ca5dccd32f6fbb6d908dfe73531 Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Feb 03 2023 11:06:30 +0000 Subject: [PATCH 3/10] mingw: remove pointless line breaks in table headers Signed-off-by: Daniel P. Berrangé --- diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc index 82670ce..12cd2a1 100644 --- a/guidelines/modules/ROOT/pages/MinGW.adoc +++ b/guidelines/modules/ROOT/pages/MinGW.adoc @@ -202,8 +202,7 @@ Generic macros: [cols=",,",] |================================================================================================================================================== -|Macro |Available in + -mingw-filesystem |Explanation +|Macro |Available in mingw-filesystem |Explanation |mingw_cmake |>= 95 |Call the 'cmake' binary for all the configured targets |mingw_cmake_kde4 |>= 95 |Call the 'cmake' binary for all the configured targets with KDE4 specific parameters set |mingw_configure |>= 95 |Call the configure command for all the configured targets @@ -223,8 +222,7 @@ Win32 specific macros: [cols=",,,",] |=================================================================================================================================================== -|Macro |Available in + -mingw32-filesystem | Value |Explanation +|Macro |Available in mingw32-filesystem | Value |Explanation |mingw32_ar |>= 95 |i686-w64-mingw32-ar |cross compiler 'ar' binary |mingw32_cc |>= 95 |i686-w64-mingw32-gcc |cross compiler 'gcc' binary |mingw32_cflags |>= 95 |-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 |Default compiler flags for C/C++ binaries @@ -249,8 +247,7 @@ Win64 specific macros: [cols=",,,",] |=================================================================================================================================================== -|Macro |Available in + -mingw64-filesystem | Value |Explanation +|Macro |Available in mingw64-filesystem | Value |Explanation |mingw64_ar |>= 95 |x86_64-w64-mingw32-ar |cross compiler 'ar' binary |mingw64_cc |>= 95 |x86_64-w64-mingw32-gcc |cross compiler 'gcc' binary |mingw64_cflags |>= 95 |-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 |Default compiler flags for C/C++ binaries From 857e0312c00d8b6bff5b9e0817bef47d92bf5164 Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Feb 03 2023 11:06:30 +0000 Subject: [PATCH 4/10] mingw: remove reference to %{mingw_package_header} adding deps The %{mingw_package_header} does not express any automatic dependancy on the mingwXX-filesystem packages. This must always be explicitly added in the spec file. Signed-off-by: Daniel P. Berrangé --- diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc index 12cd2a1..c43e039 100644 --- a/guidelines/modules/ROOT/pages/MinGW.adoc +++ b/guidelines/modules/ROOT/pages/MinGW.adoc @@ -28,7 +28,7 @@ MinGW packages require special naming to denote the appropriate CPU architecture == Base packages -The base packages provide a root filesystem, base libraries, binutils (basic programs like 'strip', 'ld' etc), the compiler (gcc) and the Win32/Win64 API. Packages may need to depend on one or more of these. In particular, almost all packages should BuildRequire `+mingw32-filesystem+`, `+mingw64-filesystem+`, `+mingw32-gcc+` and `+mingw64-gcc+`. The correct Requires flags will get added automatically when the `+%{?mingw_package_header}+` macro is mentioned in the spec file (as will be described later on in these guidelines) +The base packages provide a root filesystem, base libraries, binutils (basic programs like 'strip', 'ld' etc), the compiler (gcc) and the Win32/Win64 API. Packages may need to depend on one or more of these. In particular, almost all packages should BuildRequire `+mingw32-filesystem+`, `+mingw64-filesystem+`, `+mingw32-gcc+` and `+mingw64-gcc+`. [cols=",",] |================================================================================================================================================================================================================================= @@ -369,7 +369,7 @@ Correct dependency generation is done automatically. Packagers should start thei %{?mingw_package_header} .... -All binary packages should depend on `+mingw32-filesystem+` or `+mingw64-filesystem+` (depending on the files in the package). If the line mentioned above is used then it will be added automatically, so you don't have to add it yourself +All binary packages should depend on `+mingw32-filesystem+` or `+mingw64-filesystem+` (depending on the files in the package). All specfiles should BuildRequire at least one of these (depending on the targets for which you want to build): From 2633349668552011509009b9e200b3d4dff7596d Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Feb 03 2023 11:06:30 +0000 Subject: [PATCH 5/10] mingw: stop recommending a versioned BR dep on mingwXX-filesystem All the documented mingw32/mingw64 RPM macros can be assumed to exist in all non-EOL Fedora releases. There is no common reason to write specfiles to cope with EOL Fedora releases. Thus using a versioned BR dep on the mingwXX-filesystem packages is not required, aside from in exceptional circumstances where a newly introduced macro is used. When we enable the UCRT64 target for non-toolchain packages, it might be desirable to have a versioned dep, since UCRT64 was only introduced in mingw-filesystem 133. The time for enabling UCRT64 is still TBD. Signed-off-by: Daniel P. Berrangé --- diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc index c43e039..a25dbef 100644 --- a/guidelines/modules/ROOT/pages/MinGW.adoc +++ b/guidelines/modules/ROOT/pages/MinGW.adoc @@ -373,12 +373,14 @@ All binary packages should depend on `+mingw32-filesystem+` or `+mingw64-filesys All specfiles should BuildRequire at least one of these (depending on the targets for which you want to build): -`+BuildRequires:  mingw32-filesystem >= minimum-version+` + -`+BuildRequires:  mingw64-filesystem >= minimum-version+` +`+BuildRequires:  mingw32-filesystem+` + +`+BuildRequires:  mingw64-filesystem+` and any other BuildRequires that they need. -The `+minimum-version+` must be at least 95 or any later version which provides the functionality you need +Most mingw RPM macros can be assumed to exist in all non-EOL Fedora releases. +If the package does, however, rely on a newly introduced macro, a versioned +dependancy on the `+mingw-XX-filesystem+` packages should be used. == Build architecture @@ -463,14 +465,14 @@ Source: https://fedoraproject.org/example-%{version}.tar.bz2 BuildArch: noarch -BuildRequires: mingw32-filesystem >= 113 +BuildRequires: mingw32-filesystem BuildRequires: mingw32-gcc BuildRequires: mingw32-binutils BuildRequires: mingw32-gettext BuildRequires: mingw32-win-iconv BuildRequires: mingw32-zlib -BuildRequires: mingw64-filesystem >= 113 +BuildRequires: mingw64-filesystem BuildRequires: mingw64-gcc BuildRequires: mingw64-binutils BuildRequires: mingw64-gettext From be8558f5c70393d1c28dc425202e314c2c118d2b Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Feb 03 2023 11:06:30 +0000 Subject: [PATCH 6/10] mingw: clarify the intended usage wrt selecting files to include Clarify that the MinGW package content will be used both for adhoc dev/test of Windows platform support, and for creation of Windows installers for applications. Generally this distinction won't have a major bearing on the selection of files to include in MinGW packages. It could, however, influence the inclusion of executables and documentation targetted at end users. Signed-off-by: Daniel P. Berrangé --- diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc index a25dbef..4e3c5ed 100644 --- a/guidelines/modules/ROOT/pages/MinGW.adoc +++ b/guidelines/modules/ROOT/pages/MinGW.adoc @@ -431,14 +431,28 @@ Most binaries contain debugging symbols when the package gets built. To split th The `+%{?mingw_debug_package}+` line must be placed after the `+%description tag+`. Otherwise spectool and other RPM tools may fail to function -== Executables (EXEs) +== File listing + +The MinGW packages are intended to allow developers to compile and test the +Windows support of their applications. It is furthermore expected that +developers will build Windows installers (MSIs) for their applications using +the MinGW package content. + +Thus the Fedora MinGW package file listing must include content needed to +satisfy either build/test usage or the creation of Windows installers. + +=== Executables (EXEs) Most libraries also provide executables. These can include executables which can be used to test or showcase the library in question (for example gtk3-demo.exe in mingw-gtk3). Other examples are helper executables which are used by the library itself internally (for example gspawn-win32-helper.exe in mingw-glib2). -Executables which are required for proper functionality of the libraries must be packaged in the matching mingw32/mingw64 subpackage. All other executables are discouraged, but may be packaged in optional (dependent) subpackages at a packager's discretion. +Executables which are required for proper functionality of the libraries must be +packaged in the matching mingw32/mingw64 subpackage. Other optional executables +targetted at end users should be packaged (for example certtool.exe in GNUTLS). +Executables targetted at developers are discouraged, but may be packaged in +optional (dependent) subpackages at a packager's discretion. -== Files which are already part of native packages +=== Files which are already part of native packages There are various types of files which are simply duplicates of equivalent files found in Fedora native packages. These files should not be packaged in the MinGW package. The following files don't need to be packaged in the MinGW package when their native counterpart already contains them: @@ -449,6 +463,10 @@ The following files don't need to be packaged in the MinGW package when their na * Autoconf files (`+%{mingw32_datadir}/aclocal+` / `+%{mingw64_datadir}/aclocal+`) * gtk-doc files (`+%{mingw32_datadir}/gtk-doc+` / `+%{mingw64_datadir}/gtk-doc+`) +Note, generic Documentation aimed at end users, as opposed to developers, +should be included where it is likely that application developers will want +to bundle it with their Windows installers. + == Example Specfile .... From 3bb7fe3cfd997b9d09ed204c98b5b17751dfdb6c Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Feb 03 2023 11:06:30 +0000 Subject: [PATCH 7/10] mingw: sanitize line breaks in paragraphs As a result of automated conversion from previous formats, the paragraph text is mostly unbroken long lines, but there are also some arbitrary line breaks present. Long lines lead to very unfriendly patch diffs, both for command line tools, and also online review tools like Pagure. Thus this commit breaks all paragraphs at 79 characters. Tables and formatted examples are left untouched, since their content is easier to review if it is allowed to extend to its natural formatted width. Signed-off-by: Daniel P. Berrangé --- diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc index 4e3c5ed..8e08e6f 100644 --- a/guidelines/modules/ROOT/pages/MinGW.adoc +++ b/guidelines/modules/ROOT/pages/MinGW.adoc @@ -2,22 +2,41 @@ == Introduction -The Fedora MinGW project's mission is to provide an excellent development environment for Fedora users who wish to cross-compile their programs to run on Windows, minimizing the need to use Windows at all. In the past developers have had to port and compile all of the libraries and tools they have needed, and this huge effort has happened independently many times over. We aim to eliminate duplication of work for application developers by providing a range of libraries and development tools which have already been ported to the MinGW cross-compiler environment. This means that developers will not need to recompile the application stack themselves, but can concentrate just on the changes needed to their own application. +The Fedora MinGW project's mission is to provide an excellent development +environment for Fedora users who wish to cross-compile their programs to run on +Windows, minimizing the need to use Windows at all. In the past developers have +had to port and compile all of the libraries and tools they have needed, and +this huge effort has happened independently many times over. We aim to eliminate +duplication of work for application developers by providing a range of libraries +and development tools which have already been ported to the MinGW cross-compiler +environment. This means that developers will not need to recompile the +application stack themselves, but can concentrate just on the changes needed to +their own application. The targets Win32 and Win64 are supported. == Track Fedora native package versions -In general terms, cross-compiled MinGW versions of packages which are already natively available in Fedora, should follow the native Fedora package as closely as possible. This means they should stay at the same version, include all the same patches as the native -Fedora package, and be built with the same configuration options. +In general terms, cross-compiled MinGW versions of packages which are already +natively available in Fedora, should follow the native Fedora package as closely +as possible. This means they should stay at the same version, include all the +same patches as the native Fedora package, and be built with the same +configuration options. == Follow Fedora policy -Cross compiled MinGW packages must follow Fedora policy, except where noted in this document. Cross compiled packages go through the same review process, GIT admin process etc. as other Fedora packages. +Cross compiled MinGW packages must follow Fedora policy, except where noted in +this document. Cross compiled packages go through the same review process, GIT +admin process etc. as other Fedora packages. == Package naming -MinGW packages require special naming to denote the appropriate CPU architecture the binaries have been built for. There should *never* be a package prefixed with `+mingw-+` output during a build. The `+mingw-+` prefix is exclusive for RPM spec file names and the source RPM file name. The CPU architecture specific packages are created by sections with `+%files -n mingw32-foo+` or `+%files -n mingw64-foo+`. +MinGW packages require special naming to denote the appropriate CPU architecture +the binaries have been built for. There should *never* be a package prefixed +with `+mingw-+` output during a build. The `+mingw-+` prefix is exclusive for +RPM spec file names and the source RPM file name. The CPU architecture specific +packages are created by sections with `+%files -n mingw32-foo+` or +`+%files -n mingw64-foo+`. [cols=",",] |======================================================= @@ -28,7 +47,11 @@ MinGW packages require special naming to denote the appropriate CPU architecture == Base packages -The base packages provide a root filesystem, base libraries, binutils (basic programs like 'strip', 'ld' etc), the compiler (gcc) and the Win32/Win64 API. Packages may need to depend on one or more of these. In particular, almost all packages should BuildRequire `+mingw32-filesystem+`, `+mingw64-filesystem+`, `+mingw32-gcc+` and `+mingw64-gcc+`. +The base packages provide a root filesystem, base libraries, binutils (basic +programs like 'strip', 'ld' etc), the compiler (gcc) and the Win32/Win64 API. +Packages may need to depend on one or more of these. In particular, almost all +packages should BuildRequire `+mingw32-filesystem+`, `+mingw64-filesystem+`, +`+mingw32-gcc+` and `+mingw64-gcc+`. [cols=",",] |================================================================================================================================================================================================================================= @@ -41,12 +64,16 @@ The base packages provide a root filesystem, base libraries, binutils (basic pro == Build for multiple targets -The goal of the MinGW framework is to provide an easy way for package maintainers to build their packages for multiple targets using one .spec file. To aid developers in this several RPM macros have been developed which are part of the mingw-filesystem package. -These RPM macros will be explained later on in these guidelines. +The goal of the MinGW framework is to provide an easy way for package +maintainers to build their packages for multiple targets using one .spec file. +To aid developers in this several RPM macros have been developed which are part +of the mingw-filesystem package. These RPM macros will be explained later on in +these guidelines. By default a MinGW package will be built for both the Win32 and Win64 targets. -When a package can only be built for either one of these targets this can be indicated by setting one of these: +When a package can only be built for either one of these targets this can be +indicated by setting one of these: [cols=",",] |=============================================================== @@ -56,13 +83,19 @@ When a package can only be built for either one of these targets this can be ind == One source RPM, separate binary RPMs per-target -Each cross compiled MinGW package which builds binaries for a specific target should put the binaries for that target in a separate subpackage. So if a package `+foo+` builds binaries for the Win32 and Win64 targets, then the source RPM should provide two subpackages named `+mingw32-foo+` and `+mingw64-foo+`. +Each cross compiled MinGW package which builds binaries for a specific target +should put the binaries for that target in a separate subpackage. So if a +package `+foo+` builds binaries for the Win32 and Win64 targets, then the +source RPM should provide two subpackages named `+mingw32-foo+` and +`+mingw64-foo+`. -This means that a spec file must contains %package and %files sections for all the targets. +This means that a spec file must contains %package and %files sections for all +the targets. -If a package contains translations then all calls to the `+%find_lang+` must be replaced by `+%mingw_find_lang+`. -This causes all translation filelists to be split in per-target filelists. -For example: when a spec file contains something like this: +If a package contains translations then all calls to the `+%find_lang+` must be +replaced by `+%mingw_find_lang+`. This causes all translation filelists to be +split in per-target filelists. For example: when a spec file contains something +like this: .... %install @@ -70,8 +103,9 @@ For example: when a spec file contains something like this: %mingw_find_lang foo .... -then two files will get created named `+mingw32-foo.lang+` and `+mingw64-foo.lang+`. -These file lists can be included in the %files section for the targets: +then two files will get created named `+mingw32-foo.lang+` and +`+mingw64-foo.lang+`. These file lists can be included in the %files section +for the targets: .... %files -n mingw32-foo -f mingw32-foo.lang @@ -145,9 +179,12 @@ These file lists can be included in the %files section for the targets: == Filenames of the cross-compilers and binutils -The MinGW cross-compilers and binutils are Fedora binaries and are therefore placed in `+%{_bindir}+` (i.e., `+/usr/bin+`) according to the FHS and Fedora guidelines. +The MinGW cross-compilers and binutils are Fedora binaries and are therefore +placed in `+%{_bindir}+` (i.e., `+/usr/bin+`) according to the FHS and Fedora +guidelines. -The MinGW cross-compilers and binutils which generate i686 binaries for Windows are named: +The MinGW cross-compilers and binutils which generate i686 binaries for Windows +are named: .... %{_bindir}/i686-w64-mingw32-gcc @@ -171,11 +208,15 @@ name, i.e., etc. .... -The same also applies for the x86_64 target. This target uses 'x86_64-w64-mingw32' as prefix instead of 'i686-w64-mingw32' +The same also applies for the x86_64 target. This target uses +'x86_64-w64-mingw32' as prefix instead of 'i686-w64-mingw32' == Naming of the root filesystem -The root filesystem contains Windows executables and DLLs and any other Windows-only files. It is necessary both because we need to store Windows libraries in order to link further libraries which depend on them, and also because MinGW requires a root filesystem location. +The root filesystem contains Windows executables and DLLs and any other +Windows-only files. It is necessary both because we need to store Windows +libraries in order to link further libraries which depend on them, and also +because MinGW requires a root filesystem location. The location for Win32 target is provided by the macro: @@ -191,8 +232,9 @@ And the Win64 target is provided by the macro: == Standard mingw RPM macros -The `+mingw-filesystem+` package provides a number of convenience macros for the cross compiled sysroot directories, and -toolchain. It is mandatory to use these macros in all MinGW cross compiled packages submitted to Fedora. +The `+mingw-filesystem+` package provides a number of convenience macros for +the cross compiled sysroot directories, and toolchain. It is mandatory to use +these macros in all MinGW cross compiled packages submitted to Fedora. === Toolchain macros @@ -270,7 +312,8 @@ Win64 specific macros: === Filesystem location macros -The following macros are for use in %build, %install and %files sections of the RPM spec +The following macros are for use in %build, %install and %files sections of the +RPM spec For the Win32 target: @@ -310,19 +353,26 @@ For the Win64 target: == Compilation of binaries -In order to build binaries for multiple targets we have to call commands like `+./configure+` and `+make+` multiple times (once for each target). -If one has to write this all out in a spec file then it will lead to duplicate code. -To reduce the amount of duplication, several RPM macros have been introduced to help with the compilation. -These macros are `+%mingw_configure+`, `+%mingw_cmake+`, `+%mingw_cmake_kde4+`, `+%mingw_qmake_qt4+`, `+%mingw_qmake_qt5+` and `+%mingw_make+` - -These macros use out of source compilation to build binaries for all the targets. -Almost all packages support out of source compilation or require slight patching. The only known exceptions to date are zlib and openssl. -Packages which don't support out of source compilation may require a different approach like performing everything in the %install phase. -If you happen to stumble across a package which requires a different approach feel free to contact us on the Fedora MinGW mailing list - -Some packages need to be built multiple times for each target. Examples of this are packages which have to be built once for a static version and once for a shared version. -Such packages can add a custom suffix to the build directory used. -Say you've got something like below: +In order to build binaries for multiple targets we have to call commands like +`+./configure+` and `+make+` multiple times (once for each target). If one has +to write this all out in a spec file then it will lead to duplicate code. To +reduce the amount of duplication, several RPM macros have been introduced to +help with the compilation. These macros are `+%mingw_configure+`, +`+%mingw_cmake+`, `+%mingw_cmake_kde4+`, `+%mingw_qmake_qt4+`, +`+%mingw_qmake_qt5+` and `+%mingw_make+` + +These macros use out of source compilation to build binaries for all the +targets. Almost all packages support out of source compilation or require +slight patching. The only known exceptions to date are zlib and openssl. +Packages which don't support out of source compilation may require a different +approach like performing everything in the %install phase. If you happen to +stumble across a package which requires a different approach feel free to +contact us on the Fedora MinGW mailing list + +Some packages need to be built multiple times for each target. Examples of this +are packages which have to be built once for a static version and once for a +shared version. Such packages can add a custom suffix to the build directory +used. Say you've got something like below: .... mkdir build_shared @@ -343,35 +393,48 @@ This can be rewritten to something like this: .... Most packages used the command `+make %{?_smp_mflags}+` to build the package. -In the MinGW cross compiler framework you have to use `+%mingw_make %{?_smp_mflags}+` to build the package for all configured targets. -As with the `+%mingw_configure+` macro you can also use the MINGW_BUILDDIR_SUFFIX environment variable to indicate a custom suffix to the build directory used - -To install the package the command `+make install DESTDIR=$RPM_BUILD_ROOT+` was used in almost all cases. -This can be rewritten to `+%mingw_make install DESTDIR=$RPM_BUILD_ROOT+` to install the package for all configured targets -The environment variable MINGW_BUILDDIR_SUFFIX can also be used here - -Some packages require some custom instructions before the files are ready to be packaged. Such code can remain as is. However, you may need to duplicate these instructions multiple times (for all configured targets). +In the MinGW cross compiler framework you have to use +`+%mingw_make %{?_smp_mflags}+` to build the package for all configured targets. +As with the `+%mingw_configure+` macro you can also use the +MINGW_BUILDDIR_SUFFIX environment variable to indicate a custom suffix to the +build directory used + +To install the package the command `+make install DESTDIR=$RPM_BUILD_ROOT+` was +used in almost all cases. This can be rewritten to +`+%mingw_make install DESTDIR=$RPM_BUILD_ROOT+` to install the package for all +configured targets. The environment variable MINGW_BUILDDIR_SUFFIX can also be +used here. + +Some packages require some custom instructions before the files are ready to be +packaged. Such code can remain as is. However, you may need to duplicate these +instructions multiple times (for all configured targets). == Dependencies -If a package contains binaries which depend on a DLL provided by another package, these dependencies should be expressed in the form: +If a package contains binaries which depend on a DLL provided by another +package, these dependencies should be expressed in the form: .... mingw32(foo.dll) .... -where `+foo.dll+` is the name of the DLL. The name must be converted to lowercase because Windows binaries contain case -insensitive dependencies. The form 'mingw32(foo.dll)' should be used for Win32 binaries and the form 'mingw64(foo.dll)' for Win64 binaries. +where `+foo.dll+` is the name of the DLL. The name must be converted to +lowercase because Windows binaries contain case insensitive dependencies. The +form 'mingw32(foo.dll)' should be used for Win32 binaries and the form +'mingw64(foo.dll)' for Win64 binaries. -Correct dependency generation is done automatically. Packagers should start their spec files with this line: +Correct dependency generation is done automatically. Packagers should start +their spec files with this line: .... %{?mingw_package_header} .... -All binary packages should depend on `+mingw32-filesystem+` or `+mingw64-filesystem+` (depending on the files in the package). +All binary packages should depend on `+mingw32-filesystem+` or +`+mingw64-filesystem+` (depending on the files in the package). -All specfiles should BuildRequire at least one of these (depending on the targets for which you want to build): +All specfiles should BuildRequire at least one of these (depending on the +targets for which you want to build): `+BuildRequires:  mingw32-filesystem+` + `+BuildRequires:  mingw64-filesystem+` @@ -394,26 +457,34 @@ unless they contain Fedora native executables. All libraries must be built as DLLs. -Because of the peculiarity of Windows, DLLs are stored in the `+%{mingw32_bindir}+` directory, along with a control file in -the `+%{mingw32_libdir}+` directory. For example, for a library called `+foo+` there would be: +Because of the peculiarity of Windows, DLLs are stored in the +`+%{mingw32_bindir}+` directory, along with a control file in the +`+%{mingw32_libdir}+` directory. For example, for a library called `+foo+` +there would be: .... %{mingw32_bindir}/foo.dll %{mingw32_libdir}/foo.dll.a .... -The `+foo.dll+` file is the main library, `+foo.dll.a+` is a stub linked to applications so they can find the library at runtime. All of these files are required in those locations in order to link successfully. The `+.dll+` may contain a version number although not always (e.g., `+foo-0.dll+`). +The `+foo.dll+` file is the main library, `+foo.dll.a+` is a stub linked to +applications so they can find the library at runtime. All of these files are +required in those locations in order to link successfully. The `+.dll+` may +contain a version number although not always (e.g., `+foo-0.dll+`). === Do not use %\{mingw32_bindir}/* or %\{mingw32_libdir}/* in %files section -The `+%files+` section must list DLLs and import libraries separately. Packages must NOT use `+%{mingw32_bindir}/*+` or -`+%{mingw32_libdir}/*+` +The `+%files+` section must list DLLs and import libraries separately. Packages +must NOT use `+%{mingw32_bindir}/*+` or `+%{mingw32_libdir}/*+` -The reason for this is that libtool is very fragile and will give up on building a DLL very easily. Therefore we force the name of the DLL to be listed explicitly in the `+%files+` section in order to catch this during RPM builds. +The reason for this is that libtool is very fragile and will give up on building +a DLL very easily. Therefore we force the name of the DLL to be listed +explicitly in the `+%files+` section in order to catch this during RPM builds. === Stripping -Libraries and executables should be stripped. This is done correctly and automatically if the spec file starts with this line: +Libraries and executables should be stripped. This is done correctly and +automatically if the spec file starts with this line: .... %{?mingw_package_header} @@ -421,7 +492,9 @@ Libraries and executables should be stripped. This is done correctly and automat === Debuginfo subpackage -Most binaries contain debugging symbols when the package gets built. To split the debugging symbols to a separate debuginfo package (as is done with native Fedora packages) the spec file must include these lines: +Most binaries contain debugging symbols when the package gets built. To split +the debugging symbols to a separate debuginfo package (as is done with native +Fedora packages) the spec file must include these lines: .... %{?mingw_package_header} @@ -429,7 +502,9 @@ Most binaries contain debugging symbols when the package gets built. To split th %{?mingw_debug_package} .... -The `+%{?mingw_debug_package}+` line must be placed after the `+%description tag+`. Otherwise spectool and other RPM tools may fail to function +The `+%{?mingw_debug_package}+` line must be placed after the +`+%description tag+`. Otherwise spectool and other RPM tools may fail to +function. == File listing @@ -443,8 +518,11 @@ satisfy either build/test usage or the creation of Windows installers. === Executables (EXEs) -Most libraries also provide executables. These can include executables which can be used to test or showcase the library in question (for example gtk3-demo.exe in mingw-gtk3). -Other examples are helper executables which are used by the library itself internally (for example gspawn-win32-helper.exe in mingw-glib2). +Most libraries also provide executables. These can include executables which +can be used to test or showcase the library in question (for example +gtk3-demo.exe in mingw-gtk3). Other examples are helper executables which are +used by the library itself internally (for example gspawn-win32-helper.exe in +mingw-glib2). Executables which are required for proper functionality of the libraries must be packaged in the matching mingw32/mingw64 subpackage. Other optional executables @@ -454,8 +532,10 @@ optional (dependent) subpackages at a packager's discretion. === Files which are already part of native packages -There are various types of files which are simply duplicates of equivalent files found in Fedora native packages. These files should not be packaged in the MinGW package. -The following files don't need to be packaged in the MinGW package when their native counterpart already contains them: +There are various types of files which are simply duplicates of equivalent files +found in Fedora native packages. These files should not be packaged in the MinGW +package. The following files don't need to be packaged in the MinGW package when +their native counterpart already contains them: * Man pages (`+%{mingw32_mandir}+` / `+%{mingw64_mandir}+`) * Info files (`+%{mingw32_infodir}+` / `+%{mingw64_infodir}+`) From d12471f2e5c492b23a70c565d2f45e8bbe2cd89b Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Feb 03 2023 11:06:30 +0000 Subject: [PATCH 8/10] mingw: fix mangled formatting of filesytem hierarchy The formatting of this section got mangled at one point in the document format conversion, so doesn't render cleanly currently. Switch to the pre-formatted paragraph syntax, and split it into two separate paragraphs. Signed-off-by: Daniel P. Berrangé --- diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc index 8e08e6f..6ca003f 100644 --- a/guidelines/modules/ROOT/pages/MinGW.adoc +++ b/guidelines/modules/ROOT/pages/MinGW.adoc @@ -115,67 +115,75 @@ for the targets: == Filesystem layout -`+[root]+` + -`+  |+` + -`+  +- etc+` + -`+  |   |+` + -`+  |   +- rpm+` + -`+  |       |+` + -`+  |       +- macros.mingw+` + -`+  |       +- macros.mingw32+` + -`+  |       +- macros.mingw64+` + -`+  |+` + -`+  +- usr+` + -`+      |+` + -`+      +- bin   - Links to MinGW cross compiler toolchain+` + -`+      |   |+` + -`+      |   +- i686-w64-mingw32-cpp+` + -`+      |   +- i686-w64-mingw32-gcc+` + -`+      |   +- i686-w64-mingw32-g+++` + -`+      |   +- x86_64-w64-mingw32-cpp+` + -`+      |   +- x86_64-w64-mingw32-gcc+` + -`+      |   +- x86_64-w64-mingw32-g+++` + -`+      |   +- ... etc..+` + -`+      |+` + -`+      +- lib+` + -`+      |   |+` + -`+      |   +- rpm+` + -`+      |       |+` + -`+      |       +- mingw-find-debuginfo.sh - extract debug information from Win32 and Win64 binaries+` + -`+      |       +- mingw-find-lang.sh - generates per-target file lists containing translations+` + -`+      |       +- mingw-find-provides.sh - extra DLL names+` + -`+      |       +- mingw-find-requires.sh - discover required DLL names+` + -`+      |+` + -`+      +- i686-w64-mingw32  - root of mingw toolchain and binaries for the Win32 target - see next diagram+` + -`+      +- x86_64-w64-mingw32  - root of mingw toolchain and binaries for the Win64 target - see next diagram+` - -`+/usr/i686-w64-mingw32+` + -`+/usr/x86_64-w64-mingw32+` + -`+  |+` + -`+  +- bin  - Binutils toolchain binaries for the target+` + -`+  |   |+` + -`+  |   +- ar+` + -`+  |   +- as+` + -`+  |   +- dlltool+` + -`+  |   +- ld+` + -`+  |   +- ... etc ...+` + -`+  |+` + -`+  +- lib  - Binutils toolchain support libraries / files for the target+` + -`+  |+` + -`+  +- sys-root  - root for cross compiled MinGW binaries+` + -`+      |+` + -`+      +- mingw+` + -`+          |+` + -`+          +- bin     - cross-compiled MinGW binaries & runtime DLL parts+` + -`+          +- etc     - configuration files+` + -`+          +- include - include files for cross compiled MinGW libs+` + -`+          +- lib     - cross-compiled static MinGW libraries & linktime DLL parts+` + -`+          |   |+` + -`+          |   +- pkgconfig  - pkg-config definitions for libraries+` + -`+          |+` + -`+          +- share+` + -`+              |+` + -`+              +- man+` +Integration into the main root filesystem layout is as follows: + +.... +[root] + | + +- etc + | | + | +- rpm + | | + | +- macros.mingw + | +- macros.mingw32 + | +- macros.mingw64 + | + +- usr + | + +- bin - Links to MinGW cross compiler toolchain + | | + | +- i686-w64-mingw32-cpp + | +- i686-w64-mingw32-gcc + | +- i686-w64-mingw32-g++ + | +- x86_64-w64-mingw32-cpp + | +- x86_64-w64-mingw32-gcc + | +- x86_64-w64-mingw32-g++ + | +- ... etc.. + | + +- lib + | | + | +- rpm + | | + | +- mingw-find-debuginfo.sh - extract debug information from Win32 and Win64 binaries + | +- mingw-find-lang.sh - generates per-target file lists containing translations + | +- mingw-find-provides.sh - extra DLL names + | +- mingw-find-requires.sh - discover required DLL names + | + +- i686-w64-mingw32 - root of mingw toolchain and binaries for the Win32 target - see next diagram + +- x86_64-w64-mingw32 - root of mingw toolchain and binaries for the Win64 target - see next diagram+` +.... + +The bulk of the packaged content is located under the respective MinGW root, +one of `+/usr/i686-w64-mingw32+` + `+/usr/x86_64-w64-mingw32+`: + +.... +[mingw-root] + | + +- bin - Binutils toolchain binaries for the target + | | + | +- ar + | +- as + | +- dlltool + | +- ld + | +- ... etc ... + | + +- lib - Binutils toolchain support libraries / files for the target + | + +- sys-root - root for cross compiled MinGW binaries + | + +- mingw + | + +- bin - cross-compiled MinGW binaries & runtime DLL parts + +- etc - configuration files + +- include - include files for cross compiled MinGW libs + +- lib - cross-compiled static MinGW libraries & linktime DLL parts + | | + | +- pkgconfig - pkg-config definitions for libraries + | + +- share + | + +- man +.... == Filenames of the cross-compilers and binutils From 9b8a0ad3fb6e1b4938a5492d4b1796fb87192f95 Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Feb 03 2023 11:06:30 +0000 Subject: [PATCH 9/10] mingw: remove vertical alignment of example spec field values Illustrating vertically aligned field values is undesirable as they inevitably slip out of alignment over time as changes are made. Since there is no Fedora standard for this, it doesn't make sense to promote it as a specific formatting approach in MinGW guidelines. Signed-off-by: Daniel P. Berrangé --- diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc index 6ca003f..c252926 100644 --- a/guidelines/modules/ROOT/pages/MinGW.adoc +++ b/guidelines/modules/ROOT/pages/MinGW.adoc @@ -560,30 +560,30 @@ to bundle it with their Windows installers. .... %{?mingw_package_header} -Name: mingw-example -Version: 1.0.0 -Release: 1%{?dist} -Summary: MinGW compiled example library +Name: mingw-example +Version: 1.0.0 +Release: 1%{?dist} +Summary: MinGW compiled example library -License: LGPL-2.1-or-later -URL: https://fedoraproject.org -Source: https://fedoraproject.org/example-%{version}.tar.bz2 +License: LGPL-2.1-or-later +URL: https://fedoraproject.org +Source: https://fedoraproject.org/example-%{version}.tar.bz2 -BuildArch: noarch +BuildArch: noarch -BuildRequires: mingw32-filesystem -BuildRequires: mingw32-gcc -BuildRequires: mingw32-binutils -BuildRequires: mingw32-gettext -BuildRequires: mingw32-win-iconv -BuildRequires: mingw32-zlib +BuildRequires: mingw32-filesystem +BuildRequires: mingw32-gcc +BuildRequires: mingw32-binutils +BuildRequires: mingw32-gettext +BuildRequires: mingw32-win-iconv +BuildRequires: mingw32-zlib -BuildRequires: mingw64-filesystem -BuildRequires: mingw64-gcc -BuildRequires: mingw64-binutils -BuildRequires: mingw64-gettext -BuildRequires: mingw64-win-iconv -BuildRequires: mingw64-zlib +BuildRequires: mingw64-filesystem +BuildRequires: mingw64-gcc +BuildRequires: mingw64-binutils +BuildRequires: mingw64-gettext +BuildRequires: mingw64-win-iconv +BuildRequires: mingw64-zlib %description @@ -596,28 +596,28 @@ MinGW compiled example library. # Win32 %package -n mingw32-example -Summary: MinGW compiled example library for the Win32 target +Summary: MinGW compiled example library for the Win32 target %description -n mingw32-example MinGW compiled example library for the Win32 target. %package -n mingw32-example-static -Summary: Static version of the MinGW Win32 compiled example library -Requires: mingw32-example = %{version}-%{release} +Summary: Static version of the MinGW Win32 compiled example library +Requires: mingw32-example = %{version}-%{release} %description -n mingw32-example-static Static version of the MinGW Win32 compiled example library. # Win64 %package -n mingw64-example -Summary: MinGW compiled example library for the Win64 target +Summary: MinGW compiled example library for the Win64 target %description -n mingw64-example MinGW compiled example library for the Win64 target. %package -n mingw64-example-static -Summary: Static version of the MinGW Win64 compiled example library -Requires: mingw64-example = %{version}-%{release} +Summary: Static version of the MinGW Win64 compiled example library +Requires: mingw64-example = %{version}-%{release} %description -n mingw64-example-static Static version of the MinGW Win64 compiled example library. From b36bb4097135abea9f5bff7ddc3f488fac434278 Mon Sep 17 00:00:00 2001 From: Daniel P. Berrangé Date: Feb 03 2023 11:06:30 +0000 Subject: [PATCH 10/10] mingw: add docs about ucrt64 build target This was introduced in F37 https://fedoraproject.org/wiki/Changes/F37MingwUCRT Signed-off-by: Daniel P. Berrangé --- diff --git a/guidelines/modules/ROOT/pages/MinGW.adoc b/guidelines/modules/ROOT/pages/MinGW.adoc index c252926..10e25fc 100644 --- a/guidelines/modules/ROOT/pages/MinGW.adoc +++ b/guidelines/modules/ROOT/pages/MinGW.adoc @@ -13,7 +13,10 @@ environment. This means that developers will not need to recompile the application stack themselves, but can concentrate just on the changes needed to their own application. -The targets Win32 and Win64 are supported. +The targets Win32 and Win64 are supported with the MSVCRT runtime. The target +Win64 with the UCRT runtime is also supported, however, only for the base +toolchain. Builds for UCRT are not enabled for packages above the toolchain +at this time. == Track Fedora native package versions @@ -35,14 +38,15 @@ MinGW packages require special naming to denote the appropriate CPU architecture the binaries have been built for. There should *never* be a package prefixed with `+mingw-+` output during a build. The `+mingw-+` prefix is exclusive for RPM spec file names and the source RPM file name. The CPU architecture specific -packages are created by sections with `+%files -n mingw32-foo+` or -`+%files -n mingw64-foo+`. +packages are created by sections with `+%files -n mingw32-foo+`, +`+%files -n mingw64-foo+` or `+%files -n ucrt64-foo+`. [cols=",",] |======================================================= |`+mingw-+` |Used for source package and RPM spec name -|`+mingw32-+` |Used for packages which are built for Win32 -|`+mingw64-+` |Used for packages which are built for Win64 +|`+mingw32-+` |Used for packages which are built for Win32 with the MSVCRT runtime +|`+mingw64-+` |Used for packages which are built for Win64 with the MSVCRT runtime +|`+ucrt64-+` |Used for packages which are built for Win64 with the UCRT runtime |======================================================= == Base packages @@ -55,11 +59,11 @@ packages should BuildRequire `+mingw32-filesystem+`, `+mingw64-filesystem+`, [cols=",",] |================================================================================================================================================================================================================================= -|`+mingw32-filesystem+` / `+mingw64-filesystem+` |Core filesystem directory layout, and RPM macros for spec files. Equivalent to 'filesystem' RPM -|`+mingw32-binutils+` / `+mingw64-binutils+` |Cross-compiled binutils (utilities like 'strip', 'as', 'ld') which understand Windows executables and DLLs. Equivalent to 'binutils' RPM -|`+mingw32-gcc+` / `+mingw64-gcc+` |GNU compiler collection. Compilers for C and C++ which cross-compile to a Windows target. Equivalent to gcc RPM -|`+mingw32-crt+` / `+mingw64-crt+` |Base libraries for core MinGW runtime & development environment. Equivalent to 'glibc' RPM -|`+mingw32-headers+` / `+mingw64-headers+` |Win32 and Win64 API. A free (public domain) reimplementation of the header files required to link to the Win32 and Win64 API. No direct equivalent in base Fedora - glibc-devel is closest +|`+mingw32-filesystem+` / `+mingw64-filesystem+` / `+ucrt64-filesystem+` |Core filesystem directory layout, and RPM macros for spec files. Equivalent to 'filesystem' RPM +|`+mingw32-binutils+` / `+mingw64-binutils+` / `+ucrt64-binutils+` |Cross-compiled binutils (utilities like 'strip', 'as', 'ld') which understand Windows executables and DLLs. Equivalent to 'binutils' RPM +|`+mingw32-gcc+` / `+mingw64-gcc+` / `+ucrt64-gcc+` |GNU compiler collection. Compilers for C and C++ which cross-compile to a Windows target. Equivalent to gcc RPM +|`+mingw32-crt+` / `+mingw64-crt+` / `+ucrt64-crt+` |Base libraries for core MinGW runtime & development environment. Equivalent to 'glibc' RPM +|`+mingw32-headers+` / `+mingw64-headers+` / `+ucrt64-headers+` |Win32 and Win64 API. A free (public domain) reimplementation of the header files required to link to the Win32 and Win64 API. No direct equivalent in base Fedora - glibc-devel is closest |================================================================================================================================================================================================================================= == Build for multiple targets @@ -70,24 +74,28 @@ To aid developers in this several RPM macros have been developed which are part of the mingw-filesystem package. These RPM macros will be explained later on in these guidelines. -By default a MinGW package will be built for both the Win32 and Win64 targets. +By default a MinGW package will be built for both the Win32 and Win64 targets +with the MSVCRT runtime. Building of the Win64 target with the UCRT64 runtime +is not yet enabled by default. -When a package can only be built for either one of these targets this can be -indicated by setting one of these: +When a package can only be built for a subset of these targets this can be +indicated by setting one or more of these: [cols=",",] |=============================================================== -|`+%global mingw_build_win32 0+` |Don't build for the Win32 target -|`+%global mingw_build_win64 0+` |Don't build for the Win64 target +|`+%global mingw_build_win32 0+` |Don't build for the Win32 target with the MSVCRT runtime +|`+%global mingw_build_win64 0+` |Don't build for the Win64 target with the MSVCRT runtime +|`+%global mingw_build_ucrt64 0+` |Don't build for the Win64 target with the UCRT runtime |=============================================================== == One source RPM, separate binary RPMs per-target Each cross compiled MinGW package which builds binaries for a specific target should put the binaries for that target in a separate subpackage. So if a -package `+foo+` builds binaries for the Win32 and Win64 targets, then the -source RPM should provide two subpackages named `+mingw32-foo+` and -`+mingw64-foo+`. +package `+foo+` builds binaries for the Win32 and Win64 targets with the MSVCRT +runtime, then the source RPM should provide two subpackages named `+mingw32-foo+` +and `+mingw64-foo+`. If a package builds for the UCRT runtime, it will also +have a `+ucrt64-foo+` subpackage. This means that a spec file must contains %package and %files sections for all the targets. @@ -103,14 +111,16 @@ like this: %mingw_find_lang foo .... -then two files will get created named `+mingw32-foo.lang+` and -`+mingw64-foo.lang+`. These file lists can be included in the %files section -for the targets: +then one file per mingw target will get created named `+mingw32-foo.lang+`, +`+mingw64-foo.lang+`, and `+ucrt64-foo.lang+`. These file lists can be +included in the %files section for the targets: .... %files -n mingw32-foo -f mingw32-foo.lang %files -n mingw64-foo -f mingw64-foo.lang + + %files -n ucrt64-foo -f ucrt64-foo.lang .... == Filesystem layout @@ -138,6 +148,9 @@ Integration into the main root filesystem layout is as follows: | +- x86_64-w64-mingw32-cpp | +- x86_64-w64-mingw32-gcc | +- x86_64-w64-mingw32-g++ + | +- x86_64-w64-mingw32ucrt-cpp + | +- x86_64-w64-mingw32ucrt-gcc + | +- x86_64-w64-mingw32ucrt-g++ | +- ... etc.. | +- lib @@ -149,12 +162,14 @@ Integration into the main root filesystem layout is as follows: | +- mingw-find-provides.sh - extra DLL names | +- mingw-find-requires.sh - discover required DLL names | - +- i686-w64-mingw32 - root of mingw toolchain and binaries for the Win32 target - see next diagram - +- x86_64-w64-mingw32 - root of mingw toolchain and binaries for the Win64 target - see next diagram+` + +- i686-w64-mingw32 - root of mingw toolchain and binaries for the Win32 target with MSVCRT runtime - see next diagram + +- x86_64-w64-mingw32 - root of mingw toolchain and binaries for the Win64 target with MSVCRT runtime - see next diagram+` + +- x86_64-w64-mingw32urt - root of mingw toolchain and binaries for the Win64 target with UCRT runtime - see next diagram+` .... The bulk of the packaged content is located under the respective MinGW root, -one of `+/usr/i686-w64-mingw32+` + `+/usr/x86_64-w64-mingw32+`: +one of `+/usr/i686-w64-mingw32+`, `+/usr/x86_64-w64-mingw32+` and +`+/usr/x86_64-w64-mingw32ucrt+`: .... [mingw-root] @@ -192,7 +207,7 @@ placed in `+%{_bindir}+` (i.e., `+/usr/bin+`) according to the FHS and Fedora guidelines. The MinGW cross-compilers and binutils which generate i686 binaries for Windows -are named: +with the MSVCRT runtime are named: .... %{_bindir}/i686-w64-mingw32-gcc @@ -216,8 +231,10 @@ name, i.e., etc. .... -The same also applies for the x86_64 target. This target uses -'x86_64-w64-mingw32' as prefix instead of 'i686-w64-mingw32' +The same also applies for the x86_64 target with both MSVCRT +and UCRT runtimes. The target with MSVCRT uses 'x86_64-w64-mingw32' +as prefix instead of 'i686-w64-mingw32', while UCRT uses +'x86_64-w64-mingw32ucrt'. == Naming of the root filesystem @@ -226,18 +243,26 @@ Windows-only files. It is necessary both because we need to store Windows libraries in order to link further libraries which depend on them, and also because MinGW requires a root filesystem location. -The location for Win32 target is provided by the macro: +The location for Win32 target with MSVCRT runtime is provided by the macro: .... %{mingw32_sysroot} %{_prefix}/i686-w64-mingw32/sys-root .... -And the Win64 target is provided by the macro: +The Win64 target with MSVCRT runtime is provided by the macro: .... %{mingw64_sysroot} %{_prefix}/x86_64-w64-mingw32/sys-root .... +The Win64 target with UCRT runtime is provided by the macro: + +.... + %{ucrt64_sysroot} %{_prefix}/x86_64-w64-mingw32ucrt/sys-root +.... + + + == Standard mingw RPM macros The `+mingw-filesystem+` package provides a number of convenience macros for @@ -268,7 +293,7 @@ Generic macros: |mingw_strip |>= 95 |cross compiler 'strip' binary (which supports both Win32 and Win64 binaries) |================================================================================================================================================== -Win32 specific macros: +Win32 with MSVCRT runtime specific macros: [cols=",,,",] |=================================================================================================================================================== @@ -293,7 +318,7 @@ Win32 specific macros: |mingw32_target |>= 95 |i686-w64-mingw32 |Target platform for build |=================================================================================================================================================== -Win64 specific macros: +Win64 with MSVCRT runtime specific macros: [cols=",,,",] |=================================================================================================================================================== @@ -318,12 +343,37 @@ Win64 specific macros: |mingw64_target |>= 95 |x86_64-w64-mingw32 |Target platform for build |=================================================================================================================================================== +Win64 with UCRT runtime specific macros: + +[cols=",,,",] +|=================================================================================================================================================== +|Macro |Available in ucrt64-filesystem | Value |Explanation +|ucrt64_ar |>= 133 |x86_64-w64-mingw32ucrt-ar |cross compiler 'ar' binary +|ucrt64_cc |>= 133 |x86_64-w64-mingw32ucrt-gcc |cross compiler 'gcc' binary +|ucrt64_cflags |>= 133 |-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 |Default compiler flags for C/C++ binaries +|ucrt64_cmake |>= 133 | |Call the 'cmake' binary for the Win64 target +|ucrt64_configure |>= 133 | |standard invocation for autotools 'configure' scripts +|ucrt64_cpp |>= 133 |x86_64-w64-mingw32ucrt-gcc -E |cross compiler 'cpp' binary +|ucrt64_env |>= 133 | |Set the correct environment variables for the Win64 target +|ucrt64_host |>= 133 |x86_64-w64-mingw32 |Host platform for build +|ucrt64_meson |>= 104 | |Call the meson binary for the Win64 target +|ucrt64_ninja |>= 104 | |Call the ninja binary for the Win64 target +|ucrt64_objcopy |>= 133 |x86_64-w64-mingw32ucrt-objcopy |cross compiler 'objcopy' binary +|ucrt64_objdump |>= 133 |x86_64-w64-mingw32ucrt-objdump |cross compiler 'objdump' binary +|ucrt64_pkg_config |>= 133 |x86_64-w64-mingw32ucrt-pkg-config |Call the pkg-config command for the Win64 target +|ucrt64_qmake_qt4 |>= 133 |ucrt64-qmake-qt4 |Call the Qt4 qmake command for the Win64 target +|ucrt64_qmake_qt5 |>= 133 |ucrt64-qmake-qt5 |Call the Qt5 qmake command for the Win64 target +|ucrt64_ranlib |>= 133 |x86_64-w64-mingw32ucrt-ranlib |cross compiler 'ranlib' binary +|ucrt64_strip |>= 133 |x86_64-w64-mingw32ucrt-strip |cross compiler 'strip' binary +|ucrt64_target |>= 133 |x86_64-w64-mingw32 |Target platform for build +|=================================================================================================================================================== + === Filesystem location macros The following macros are for use in %build, %install and %files sections of the RPM spec -For the Win32 target: +For the Win32 with MSVCRT runtime target: [cols=",,",] |=================================================================================================== @@ -341,7 +391,7 @@ For the Win32 target: |mingw32_sysroot |%\{_prefix}/i686-w64-mingw32/sys-root |Windows system root. |=================================================================================================== -For the Win64 target: +For the Win64 with MSVCRT runtime target: [cols=",,",] |=================================================================================================== @@ -359,6 +409,24 @@ For the Win64 target: |mingw64_sysroot |%\{_prefix}/x86_64-w64-mingw32/sys-root |Windows system root. |=================================================================================================== +For the Win64 with UCRT runtime target: + +[cols=",,",] +|=================================================================================================== +|ucrt64_bindir |%\{ucrt64_prefix}/bin |Location of Windows executables. +|ucrt64_datadir |%\{ucrt64_prefix}/share |Shared data used under Windows. +|ucrt64_docdir |%\{ucrt64_prefix}/share/doc |Documentation. +|ucrt64_infodir |%\{ucrt64_prefix}/share/info |Info files (see note below). +|ucrt64_includedir |%\{ucrt64_prefix}/include |Header files used when cross-compiling for Windows. +|ucrt64_libdir |%\{ucrt64_prefix}/lib |Windows libraries (see sections below). +|ucrt64_libexecdir |%\{ucrt64_prefix}/libexec | +|ucrt64_mandir |%\{ucrt64_prefix}/share/man |Man pages (see note below). +|ucrt64_prefix |%\{ucrt64_sysroot}/mingw |Windows equivalent of %\{_prefix}, required by MinGW. +|ucrt64_sbindir |%\{ucrt64_prefix}/sbin | +|ucrt64_sysconfdir |%\{ucrt64_prefix}/etc |Configuration files used when running under Windows. +|ucrt64_sysroot |%\{_prefix}/x86_64-w64-mingw32ucrt/sys-root |Windows system root. +|=================================================================================================== + == Compilation of binaries In order to build binaries for multiple targets we have to call commands like @@ -545,11 +613,11 @@ found in Fedora native packages. These files should not be packaged in the MinGW package. The following files don't need to be packaged in the MinGW package when their native counterpart already contains them: -* Man pages (`+%{mingw32_mandir}+` / `+%{mingw64_mandir}+`) -* Info files (`+%{mingw32_infodir}+` / `+%{mingw64_infodir}+`) -* Generic documentation (`+%{mingw32_docdir}+` / `+%{mingw64_docdir}+`) -* Autoconf files (`+%{mingw32_datadir}/aclocal+` / `+%{mingw64_datadir}/aclocal+`) -* gtk-doc files (`+%{mingw32_datadir}/gtk-doc+` / `+%{mingw64_datadir}/gtk-doc+`) +* Man pages (`+%{mingw32_mandir}+` / `+%{mingw64_mandir}+` / `+%{ucrt64_mandir}+`) +* Info files (`+%{mingw32_infodir}+` / `+%{mingw64_infodir}+` / `+%{ucrt64_infodir}+`) +* Generic documentation (`+%{mingw32_docdir}+` / `+%{mingw64_docdir}+` / `+%{ucrt64_docdir}+`) +* Autoconf files (`+%{mingw32_datadir}/aclocal+` / `+%{mingw64_datadir}/aclocal+` / `+%{ucrt64_datadir}/aclocal+`) +* gtk-doc files (`+%{mingw32_datadir}/gtk-doc+` / `+%{mingw64_datadir}/gtk-doc+` / `+%{ucrt64_datadir}/gtk-doc+`) Note, generic Documentation aimed at end users, as opposed to developers, should be included where it is likely that application developers will want