English Portuguese (Brazil)
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+`.
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:
%install
<snip>
%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:
%files -n mingw32-foo -f mingw32-foo.lang
<snip>
%files -n mingw64-foo -f mingw64-foo.lang
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+`
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 which generate i686 binaries for Windows are named:
%{_bindir}/i686-w64-mingw32-gcc
%{_bindir}/i686-w64-mingw32-g++
%{_bindir}/i686-w64-mingw32-ld
%{_bindir}/i686-w64-mingw32-as
%{_bindir}/i686-w64-mingw32-strip
etc.
The same binaries are present in `+%{_prefix}/i686-w64-mingw32/bin+` without any prefix in the name, i.e.,
%{_prefix}/i686-w64-mingw32/bin/gcc
%{_prefix}/i686-w64-mingw32/bin/g++
%{_prefix}/i686-w64-mingw32/bin/ld
%{_prefix}/i686-w64-mingw32/bin/as
%{_prefix}/i686-w64-mingw32/bin/strip
etc.
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 location for Win32 target is provided by the macro: