Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

upgrade to MinGW 4 #323

Closed
wants to merge 13 commits into from
Closed

upgrade to MinGW 4 #323

wants to merge 13 commits into from

Conversation

@mabrand
Copy link
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
Copy link
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.
@tonytheodore
Copy link
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
Copy link
Member Author

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
Copy link
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
Copy link
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
Copy link
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
Copy link
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
Copy link
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 mentioned this pull request Apr 3, 2014
@tonytheodore
Copy link
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
Copy link
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
Copy link
Member Author

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
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.