Repository navigation
Conversation
|
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:
|
I checked gcc/binutils with: and it's safe to use 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? |
|
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. |
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 ;)
Agreed. It means specifying a few extra rules, but provides better separation than a 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. |
|
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. |
|
A couple of fixes: w32api typo (allowing wxwidgets to build with relaxed warnings in the test) and libbluray - How are you creating patches these days, the patch tool doesn't seem to work one these? |
|
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 |
|
With the trunk version 5 packages are already fixed and 4 more work with forcing the detection of |
Otherwise gdal won't find getaddrinfo using mingw4.
Assume that we don't need pgwin32_safestat in client code. The redefinition of struct stat and stat() causes problems because it assumes the real stat() is a function. In fact, it's a macro in w32api.
|
There's been no development on the v4 trunk since January and it looks like it may be on hold: |
|
See http://sourceforge.net/p/mingw/mailman/message/32670608/. Keith Marshall, a MinGW developer, recommends against using WSL-4. |
|
MinGW 4 doesn't seem to be moving, so let's just put this on hold. |
3 participants
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.