upgrade to MinGW 4 #323

Closed
wants to merge 13 commits into
from

Conversation

Projects
None yet
3 participants
@mabrand
Member

mabrand commented Feb 14, 2014

There are 19 packages that don't yet build with MinGW 4, so it's probably too early to merge this. But please feel free to have a look and comment.

@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Feb 15, 2014

Member

Nice work! I haven't had a chance to test this yet, but I'd suggest we try to merge it sooner rather than later. I'd propose to:

  • add as a new target so we can run it side-by-side. I'm 99% sure we could use i686-wsl-mingw32 (it's only *-w64-* that has special meaning to binutils/gcc), but i686-pc-mingw32.static.wsl is safe.
  • build the crt from development trunk rather than use released versions. I have an experimental branch for this that looks like it's partly done.
Member

tonytheodore commented Feb 15, 2014

Nice work! I haven't had a chance to test this yet, but I'd suggest we try to merge it sooner rather than later. I'd propose to:

  • add as a new target so we can run it side-by-side. I'm 99% sure we could use i686-wsl-mingw32 (it's only *-w64-* that has special meaning to binutils/gcc), but i686-pc-mingw32.static.wsl is safe.
  • build the crt from development trunk rather than use released versions. I have an experimental branch for this that looks like it's partly done.

@TimothyGu TimothyGu referenced this pull request in mpv-player/mpv Feb 15, 2014

Closed

M_PI undefined in mxe i686-w64-mingw32 #544

@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Feb 15, 2014

Member

I'm 99% sure we could use i686-wsl-mingw32

I checked gcc/binutils with:

grep '\-pc\-' -r gcc-4.8.2/ | grep -v 'NEWS\|ChangeLog\|config.guess\|\.html\|testsuite\|\.texi\|\.info'

and it's safe to use *-wsl-* instead of *-pc-*.

The trunk builds with some minor changes to your patches (duplicate mingw subdirectory in mingwrt?) and seems like an option if we want the latest version.

Do we want to install these side-by-side or replace the current version?

Member

tonytheodore commented Feb 15, 2014

I'm 99% sure we could use i686-wsl-mingw32

I checked gcc/binutils with:

grep '\-pc\-' -r gcc-4.8.2/ | grep -v 'NEWS\|ChangeLog\|config.guess\|\.html\|testsuite\|\.texi\|\.info'

and it's safe to use *-wsl-* instead of *-pc-*.

The trunk builds with some minor changes to your patches (duplicate mingw subdirectory in mingwrt?) and seems like an option if we want the latest version.

Do we want to install these side-by-side or replace the current version?

@mabrand

This comment has been minimized.

Show comment
Hide comment
@mabrand

mabrand Feb 15, 2014

Member

I just cherry-picked the patches that weren't specific to the mingwrt/w32api upgrade and pushed them into the master branch, then rebased the mingwrt branch on master.

Some of the packages that don't build have problems because of symbols (functions) missing from the libraries. I don't have a list ready, but I think some of the more exotic string functions are in this condition. If you use the development trunk instead of the released packages, is it easy to add the missing functions to the libraries? In any case, feel free to use my patches any way at all of course.

Adding this as -wsl- side-by-side with version 3 as -pc- seems reasonable, at least as long as version 4 doesn't cover all the packages covered by 3. At some point I suppose we would drop version 3 for the sake of having less to maintain.

I don't have any 64-bit experience yet with mingw.org version 4, although I understand it's supposed to work. If anybody would like to work on that, please feel free.

Member

mabrand commented Feb 15, 2014

I just cherry-picked the patches that weren't specific to the mingwrt/w32api upgrade and pushed them into the master branch, then rebased the mingwrt branch on master.

Some of the packages that don't build have problems because of symbols (functions) missing from the libraries. I don't have a list ready, but I think some of the more exotic string functions are in this condition. If you use the development trunk instead of the released packages, is it easy to add the missing functions to the libraries? In any case, feel free to use my patches any way at all of course.

Adding this as -wsl- side-by-side with version 3 as -pc- seems reasonable, at least as long as version 4 doesn't cover all the packages covered by 3. At some point I suppose we would drop version 3 for the sake of having less to maintain.

I don't have any 64-bit experience yet with mingw.org version 4, although I understand it's supposed to work. If anybody would like to work on that, please feel free.

@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Feb 15, 2014

Member

If you use the development trunk instead of the released packages, is it easy to add the missing functions to the libraries?

I'd say it's neither more nor less easy, just cleaner as you can implement those functions and re-build the libraries without doing tricky things in the headers - the latter being the only point of leverage in the (binary) releases. The main benefit though, is that someone else may have already fixed it ;)

Adding this as -wsl- side-by-side with version 3 as -pc- seems reasonable

Agreed. It means specifying a few extra rules, but provides better separation than a .wsl suffix.

I'd say you should merge this once it's side-by-side ready, having an extra target is very lightweight and gives people the chance to start using it - I've heard many anecdotes about how ancient mingw.org is, so the sooner we get this out - the better. We can add the trunk build later to see if it helps with any of the remaining packages.

Member

tonytheodore commented Feb 15, 2014

If you use the development trunk instead of the released packages, is it easy to add the missing functions to the libraries?

I'd say it's neither more nor less easy, just cleaner as you can implement those functions and re-build the libraries without doing tricky things in the headers - the latter being the only point of leverage in the (binary) releases. The main benefit though, is that someone else may have already fixed it ;)

Adding this as -wsl- side-by-side with version 3 as -pc- seems reasonable

Agreed. It means specifying a few extra rules, but provides better separation than a .wsl suffix.

I'd say you should merge this once it's side-by-side ready, having an extra target is very lightweight and gives people the chance to start using it - I've heard many anecdotes about how ancient mingw.org is, so the sooner we get this out - the better. We can add the trunk build later to see if it helps with any of the remaining packages.

@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Mar 1, 2014

Member

Now I think that running them side-by-side isn't such a good idea. We'll have to switch it over at some stage and there's no way to determine a threshold on the number of updated packages that would make it ready.

I'd say you should merge this now so we can focus on the remaining packages rather than the dual maintenance.

Member

tonytheodore commented Mar 1, 2014

Now I think that running them side-by-side isn't such a good idea. We'll have to switch it over at some stage and there's no way to determine a threshold on the number of updated packages that would make it ready.

I'd say you should merge this now so we can focus on the remaining packages rather than the dual maintenance.

@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Mar 1, 2014

Member

A couple of fixes: w32api typo (allowing wxwidgets to build with relaxed warnings in the test) and libbluray -
tonytheodore/mxe@eecda5d...cb275ed

How are you creating patches these days, the patch tool doesn't seem to work one these?

Member

tonytheodore commented Mar 1, 2014

A couple of fixes: w32api typo (allowing wxwidgets to build with relaxed warnings in the test) and libbluray -
tonytheodore/mxe@eecda5d...cb275ed

How are you creating patches these days, the patch tool doesn't seem to work one these?

@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Mar 1, 2014

Member

libm.a appears to have no symbols in it - I'll try with the trunk version to see if mirror/mingw-org-wsl@089a996 fixes it

Member

tonytheodore commented Mar 1, 2014

libm.a appears to have no symbols in it - I'll try with the trunk version to see if mirror/mingw-org-wsl@089a996 fixes it

@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Mar 1, 2014

Member

With the trunk version 5 packages are already fixed and 4 more work with forcing the detection of strcasecmp | strncasecmp

Member

tonytheodore commented Mar 1, 2014

With the trunk version 5 packages are already fixed and 4 more work with forcing the detection of strcasecmp | strncasecmp

@tonytheodore tonytheodore referenced this pull request Apr 3, 2014

Merged

Sdl2 shared #363

@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Apr 3, 2014

Member

There's been no development on the v4 trunk since January and it looks like it may be on hold:
http://sourceforge.net/p/mingw/bugs/2202/#fc56

Member

tonytheodore commented Apr 3, 2014

There's been no development on the v4 trunk since January and it looks like it may be on hold:
http://sourceforge.net/p/mingw/bugs/2202/#fc56

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 12, 2014

Member

See http://sourceforge.net/p/mingw/mailman/message/32670608/. Keith Marshall, a MinGW developer, recommends against using WSL-4.

Member

TimothyGu commented Aug 12, 2014

See http://sourceforge.net/p/mingw/mailman/message/32670608/. Keith Marshall, a MinGW developer, recommends against using WSL-4.

@mabrand

This comment has been minimized.

Show comment
Hide comment
@mabrand

mabrand Aug 28, 2014

Member

MinGW 4 doesn't seem to be moving, so let's just put this on hold.

Member

mabrand commented Aug 28, 2014

MinGW 4 doesn't seem to be moving, so let's just put this on hold.

@mabrand mabrand closed this Aug 28, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment