We haven't upgraded mingw in ages. First we need to have another look at the state of the mingw vs mingw64 war though. Perhaps we should use the same project for both win32 and win64.
Thread / flamewar about "Harmonizing mingwrt / w32api with mingw-w64": http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3383 5 years old though.
My conclusion is that the mingw and mingw-w64 projects will not merge anytime soon, probably never. As far as I can tell, the MinGW project has also not yet produced any working 64 bit toolchain. MinGW-W64 seems to be what people are using in practice. It's used by major projects such as QT (http://qt-project.org/wiki/MinGW-64-bit). Although the MinGW code is also fine and stable, I see clear advantages in using the same MinGW for both our 32 and 64-bit builds, and since the MinGW project does not support 64 bits, the decision is pretty easy for me: Switch to MinGW-w64.
We are currently using MinGW-W64 20120227. When fixing bug 5256, the plan is to upgrade from GCC 4.5.4 to 4.7.4. Unfortunately, this GCC cannot build this MinGW, due to some issues with __mingw_snprintf. My plan was to start with this bug; start with upgrading to the latest MinGW version: 3.3.0. Unfortunately, this version cannot be compiled with GCC 4.5.4... This version of MinGW requires __int128, which was added in GCC 4.6.
tlclient now builds with MinGW 3.3, after fixes in r29823.
(In reply to comment #4) > tlclient now builds with MinGW 3.3, after fixes in r29823. More fixes in 29828.
Doing for 4.4, since it's related to the GCC upgrade, and I've done most of the job already.
MinGW upgraded in cenbuild r29829.
The left side image is broken in the Windows installers. Taking a wild guess that the mingw upgrade is what caused it.
(In reply to comment #8) > The left side image is broken in the Windows installers. Taking a wild guess > that the mingw upgrade is what caused it. Fixed in cenbuild r29940.
The sysroot-headers package has no build requirements, which is incorrect as it runs both configure and make.
libtasn1 also fails to build: msvc-inval.c:32:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gl_msvc_invalid_parameter_handler' msvc-inval.c: In function 'gl_msvc_inval_ensure_handler': msvc-inval.c:124:39: error: 'gl_msvc_invalid_parameter_handler' undeclared (first use in this function) msvc-inval.c:124:39: note: each undeclared identifier is reported only once for each function it appears in
(In reply to comment #10) > The sysroot-headers package has no build requirements, which is incorrect as it > runs both configure and make. r30223.
(In reply to comment #11) > libtasn1 also fails to build: > > msvc-inval.c:32:1: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'gl_msvc_invalid_parameter_handler' > msvc-inval.c: In function 'gl_msvc_inval_ensure_handler': > msvc-inval.c:124:39: error: 'gl_msvc_invalid_parameter_handler' undeclared > (first use in this function) > msvc-inval.c:124:39: note: each undeclared identifier is reported only once for > each function it appears in This is fixed upstream, so the easiest approach is simply to update libtasn1. Handled on bug 5292.
It is now possible to build all of cenbuild. The rest of the testing will be indirect via all other tests.
