Bug 5287 - upgrade mingw
Summary: upgrade mingw
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Build system (show other bugs)
Version: pre-1.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.4.0
Assignee: Peter Åstrand
URL:
Keywords: ossman_tester, prosaic
Depends on: 5295
Blocks: 5256
  Show dependency treegraph
 
Reported: 2014-10-09 10:58 CEST by Pierre Ossman
Modified: 2015-04-16 11:09 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2014-10-09 10:58:43 CEST
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.
Comment 1 Peter Åstrand cendio 2015-01-13 09:28:54 CET
Thread / flamewar about "Harmonizing mingwrt / w32api with mingw-w64":

http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3383

5 years old though.
Comment 2 Peter Åstrand cendio 2015-01-13 09:45:43 CET
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.
Comment 3 Peter Åstrand cendio 2015-01-14 13:26:21 CET
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.
Comment 4 Peter Åstrand cendio 2015-01-21 13:06:04 CET
tlclient now builds with MinGW 3.3, after fixes in r29823.
Comment 5 Peter Åstrand cendio 2015-01-21 16:12:13 CET
(In reply to comment #4)
> tlclient now builds with MinGW 3.3, after fixes in r29823.

More fixes in 29828.
Comment 6 Peter Åstrand cendio 2015-01-21 16:14:11 CET
Doing for 4.4, since it's related to the GCC upgrade, and I've done most of the job already.
Comment 7 Peter Åstrand cendio 2015-01-21 16:23:51 CET
MinGW upgraded in cenbuild r29829.
Comment 8 Pierre Ossman cendio 2015-01-30 14:04:43 CET
The left side image is broken in the Windows installers. Taking a wild guess that the mingw upgrade is what caused it.
Comment 9 Peter Åstrand cendio 2015-02-05 16:22:10 CET
(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.
Comment 10 Pierre Ossman cendio 2015-04-08 16:32:44 CEST
The sysroot-headers package has no build requirements, which is incorrect as it runs both configure and make.
Comment 11 Pierre Ossman cendio 2015-04-09 11:14:37 CEST
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
Comment 12 Pierre Ossman cendio 2015-04-10 10:14:38 CEST
(In reply to comment #10)
> The sysroot-headers package has no build requirements, which is incorrect as it
> runs both configure and make.

r30223.
Comment 13 Pierre Ossman cendio 2015-04-15 11:01:30 CEST
(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.
Comment 14 Pierre Ossman cendio 2015-04-16 11:09:20 CEST
It is now possible to build all of cenbuild. The rest of the testing will be indirect via all other tests.

Note You need to log in before you can comment on or make changes to this bug.