MinGW GCC 4.8
Update the mingw-gcc cross-compiler to gcc 4.8 and rebuild all MinGW packages against it
- Name: Erik van Pienbroek
- Email: email@example.com
- Targeted release: Fedora 19
- Last updated: 2013-01-26
- Percentage of completion: 50%
The Fedora MinGW SIG maintains over a large number of packages which allows users to build binaries for the win32 and win64 targets using the mingw-w64 toolchain. One of the goals of the Fedora MinGW SIG is to have the package versions as close as possible to their native counterparts: https://fedoraproject.org/wiki/Packaging:MinGW?rd=Packaging/MinGW#Track_Fedora_native_package_versions As gcc 4.8 was accepted as a feature for Fedora 19 we intend to update the mingw-gcc package in Fedora 19 as well to gcc 4.8
Benefit to Fedora
See http://gcc.gnu.org/gcc-4.8/changes.html for the list of changes
The introduction of mingw-gcc 4.8 can be split in the following sub-tasks:
- Update mingw-gcc to version 4.8 in a local environment done
- Perform a test mass rebuild against this updated mingw-gcc package done, results
- Identify build failures done, results
- Resolve build failures in progress, 2 packages remaining, mingw-qpid-cpp and wine-mono
- Introduce mingw-gcc 4.8 in rawhide
- Rebuild all mingw-* packages which depend on libgcc_s_sjlj-1.dll (upstream switched to SEH exception handling for the win64 target by default)
- Have all other mingw-* packages rebuild by the mass rebuild which will start on February 1 2013
How To Test
The Fedora MinGW SIG maintains a testsuite which performs regression testing. Other tests can be done by building packages against it and testing out the compiled results on native win32/win64 environments or by using wine.
Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and C11 support, improved vectorization support, etc.
Dependencies / Affected packages
All mingw-* packages and wine-mono need to be rebuild after mingw-gcc 4.8 is introduced in rawhide.
The list of packages which need to be rebuild directly after the introduction of mingw-gcc 4.8 to prevent broken dependencies are:
$ repoquery --whatrequires 'mingw64(libgcc_s_sjlj-1.dll)' --disablerepo=\* --enablerepo=rawhide --source | sort | uniq mingw-antlr-2.7.7-10.fc18.src.rpm mingw-atkmm-2.22.6-5.fc18.src.rpm mingw-boost-1.50.0-1.fc19.src.rpm mingw-cairomm-1.10.0-8.fc18.src.rpm mingw-clucene-188.8.131.52-5.fc19.src.rpm mingw-cximage-600-7.fc19.src.rpm mingw-enchant-1.6.0-7.fc19.src.rpm mingw-glibmm24-2.34.1-1.fc18.src.rpm mingw-gmp-5.0.5-1.fc19.src.rpm mingw-gnutls-2.12.21-2.fc19.src.rpm mingw-gtkmm24-2.24.2-7.fc18.src.rpm mingw-gtkmm30-3.6.0-1.fc18.src.rpm mingw-harfbuzz-0.9.9-2.fc19.src.rpm mingw-hunspell-1.3.2-8.fc19.src.rpm mingw-icu-49.1.2-1.fc19.src.rpm mingw-libsigc++20-2.2.11-1.fc18.src.rpm mingw-libsqlite3x-20071018-17.fc19.src.rpm mingw-libxml++-2.36.0-1.fc18.src.rpm mingw-pangomm-2.28.4-4.fc18.src.rpm mingw-pcre-8.31-1.fc19.src.rpm mingw-polyclipping-5.0.3-3.fc19.src.rpm mingw-pthreads-2.8.0-22.20110511cvs.fc18.src.rpm mingw-qt-4.8.4-1.fc19.src.rpm mingw-qwt-6.0.1-1.fc19.src.rpm mingw-webkitgtk-1.10.2-2.fc19.src.rpm mingw-webkitgtk3-1.10.2-2.fc19.src.rpm mingw-wxWidgets-2.8.12-12.fc19.src.rpm mingw-zfstream-20041202-15.fc19.src.rpm
These packages need to be rebuild directly because gcc upstream decided to use SEH exception handling by default for the win64 target. The library libgcc_s_sjlj-1.dll is replaced with libgcc_s_seh-1.dll for the win64 target. Therefore all packages which used to depend on libgcc_s_sjlj-1.dll need to be rebuild so they start using libgcc_s_seh-1.dll instead
In a worst-case situation then the old mingw-gcc package can be reintroduced and all mingw packages need to be rebuild another time against this older gcc
The MinGW gcc cross-compiler for the win32 and win64 targets has been updated to gcc 4.8. See http://gcc.gnu.org/gcc-4.8/changes.html for user visible changes in it.
One of the most notable changes in gcc 4.8 is that the default exception handling model for the win64 target was changed from SjLj to SEH. The win32 target still uses the SjLj exception handling model. This causes all binaries for the win64 target which use exception handling to depend on libgcc_s_seh-1.dll instead of libgcc_s_sjlj-1.dll