mingwrt w32api version 4 pilot #203

Closed
mabrand opened this Issue Jun 4, 2013 · 9 comments

Comments

Projects
None yet
3 participants
@mabrand
Member

mabrand commented Jun 4, 2013

I've done some work on using the new version 4 release candidate of mingwrt and w32api from MinGW. Many packages build now, including qtbase, gsoap, vmime.

I doubt we will want to merge this into MXE until the official release and until we have some more experience with it, but feel free to take a look:

https://github.com/mabrand/mxe/tree/mingwrt4

The branch is mingwrt4.

@tonytheodore

This comment has been minimized.

Show comment Hide comment
@tonytheodore

tonytheodore Jun 4, 2013

Member

Nice work! I've kicked off a build and will let you know how it goes.

One question, does -D WINVER=0x0600 mean XP is no longer supported?

Member

tonytheodore commented Jun 4, 2013

Nice work! I've kicked off a build and will let you know how it goes.

One question, does -D WINVER=0x0600 mean XP is no longer supported?

@mabrand

This comment has been minimized.

Show comment Hide comment
@mabrand

mabrand Jun 4, 2013

Member

The 0x0600 is needed to enable MemoryBarrier support in the winapi. Fontconfig wanted this and qtbase wanted it for opengl. I haven't figured out why the issue comes up now with version 4. We can still decide to maintain XP compatibility, but then we'll have to find other ways to make the build succeed, or perhaps disable features.

By the way, many mysterious build failures can be solved by including windows.h. There are examples of this in my work so far. I wonder if the memset fix patch could be avoided by including windows.h at the right places in packages.

The other frequent problem is that WIN32 isn't defined automatically and some packages expect it.

I'm afraid linking the test program for qtbase fails at the moment:

mxe/mingwrt4/usr/i686-pc-mingw32/qt5/plugins/platforms/libqwindows.a(qwindowsdrag.o):qwindowsdrag.cpp:(.text+0x4d9): undefined reference to `IID_IDropTargetHelper'
mxe/mingwrt4/usr/i686-pc-mingw32/qt5/plugins/platforms/libqwindows.a(qwindowsdrag.o):qwindowsdrag.cpp:(.text+0x4f0): undefined reference to `CLSID_DragDropHelper'

I had it working before, but then I fixed other things that probably switched on some features that led to this. I think these symbols used to be in libshell32.a, but now they are not. Not sure what's wrong. Maybe an upstream packaging bug.

Member

mabrand commented Jun 4, 2013

The 0x0600 is needed to enable MemoryBarrier support in the winapi. Fontconfig wanted this and qtbase wanted it for opengl. I haven't figured out why the issue comes up now with version 4. We can still decide to maintain XP compatibility, but then we'll have to find other ways to make the build succeed, or perhaps disable features.

By the way, many mysterious build failures can be solved by including windows.h. There are examples of this in my work so far. I wonder if the memset fix patch could be avoided by including windows.h at the right places in packages.

The other frequent problem is that WIN32 isn't defined automatically and some packages expect it.

I'm afraid linking the test program for qtbase fails at the moment:

mxe/mingwrt4/usr/i686-pc-mingw32/qt5/plugins/platforms/libqwindows.a(qwindowsdrag.o):qwindowsdrag.cpp:(.text+0x4d9): undefined reference to `IID_IDropTargetHelper'
mxe/mingwrt4/usr/i686-pc-mingw32/qt5/plugins/platforms/libqwindows.a(qwindowsdrag.o):qwindowsdrag.cpp:(.text+0x4f0): undefined reference to `CLSID_DragDropHelper'

I had it working before, but then I fixed other things that probably switched on some features that led to this. I think these symbols used to be in libshell32.a, but now they are not. Not sure what's wrong. Maybe an upstream packaging bug.

@nkbj

This comment has been minimized.

Show comment Hide comment
@nkbj

nkbj Jun 8, 2013

Contributor

Nice work. The harfbuzz package also need -DWINVER=0x0600 for MemoryBarrier support. I get a strange build error in gdk-pixbuf with undefined references in libmingwex.a. I will try to look for solutions. Update: The build error looks like this upstream bug: http://sourceforge.net/p/mingw/bugs/1975/

Im not completely sure, but I think WIN32 (or _WIN32) should be set by the compiler, not the runtime library.

BTW Should it not be possible to replace mingw64-w64 with the new mingwrt/w32api for 64bit support?

Best regards,
Niels Kristian Bech Jensen

Contributor

nkbj commented Jun 8, 2013

Nice work. The harfbuzz package also need -DWINVER=0x0600 for MemoryBarrier support. I get a strange build error in gdk-pixbuf with undefined references in libmingwex.a. I will try to look for solutions. Update: The build error looks like this upstream bug: http://sourceforge.net/p/mingw/bugs/1975/

Im not completely sure, but I think WIN32 (or _WIN32) should be set by the compiler, not the runtime library.

BTW Should it not be possible to replace mingw64-w64 with the new mingwrt/w32api for 64bit support?

Best regards,
Niels Kristian Bech Jensen

@tonytheodore

This comment has been minimized.

Show comment Hide comment
@tonytheodore

tonytheodore Jun 8, 2013

Member

@mabrand wrote:

We can still decide to maintain XP compatibility, but then we'll have to find other ways to make the build succeed, or perhaps disable features.

@nkbj wrote:

BTW Should it not be possible to replace mingw64-w64 with the new mingwrt/w32api for 64bit support?

I've searched through the binutils/gcc sources and while *-w64-* is significant to the configuration, *-pc-mingw* isn't (it's only mentioned in the docs, some test case, and config.guess). This means we can run them side-by-side with:

  • i686-pc-mingw32: current mingw.org 3x with broad support and backwards compatibility
  • *-w64-mingw32: mingw-w64 with fairly stable support for a large subset of packages
  • *-wsl-mingw32: new mingw.org 4x (Windows System Libraries) targeting Vista and later

That may end up being a mess though.

Im not completely sure, but I think WIN32 (or _WIN32) should be set by the compiler, not the runtime library.

That's my understanding also:

$ echo "" | i686-pc-mingw32-cpp -dM - | grep WIN32
#define _WIN32 1
#define __WIN32 1
#define __WIN32__ 1
#define WIN32 1
Member

tonytheodore commented Jun 8, 2013

@mabrand wrote:

We can still decide to maintain XP compatibility, but then we'll have to find other ways to make the build succeed, or perhaps disable features.

@nkbj wrote:

BTW Should it not be possible to replace mingw64-w64 with the new mingwrt/w32api for 64bit support?

I've searched through the binutils/gcc sources and while *-w64-* is significant to the configuration, *-pc-mingw* isn't (it's only mentioned in the docs, some test case, and config.guess). This means we can run them side-by-side with:

  • i686-pc-mingw32: current mingw.org 3x with broad support and backwards compatibility
  • *-w64-mingw32: mingw-w64 with fairly stable support for a large subset of packages
  • *-wsl-mingw32: new mingw.org 4x (Windows System Libraries) targeting Vista and later

That may end up being a mess though.

Im not completely sure, but I think WIN32 (or _WIN32) should be set by the compiler, not the runtime library.

That's my understanding also:

$ echo "" | i686-pc-mingw32-cpp -dM - | grep WIN32
#define _WIN32 1
#define __WIN32 1
#define __WIN32__ 1
#define WIN32 1
@mabrand

This comment has been minimized.

Show comment Hide comment
@mabrand

mabrand Jun 8, 2013

Member

I added a "bug" upstream about WIN32 even though I'm not sure it is one.
https://sourceforge.net/p/mingw/bugs/1987/

Member

mabrand commented Jun 8, 2013

I added a "bug" upstream about WIN32 even though I'm not sure it is one.
https://sourceforge.net/p/mingw/bugs/1987/

@mabrand

This comment has been minimized.

Show comment Hide comment
@mabrand

mabrand Jun 8, 2013

Member

By the way, at least some of the cases where extra includes of windows.h were needed should be fixed now. Also fixed are the missing symbols IID_IDropTargetHelper and CLSID_DragDropHelper.

Member

mabrand commented Jun 8, 2013

By the way, at least some of the cases where extra includes of windows.h were needed should be fixed now. Also fixed are the missing symbols IID_IDropTargetHelper and CLSID_DragDropHelper.

@nkbj

This comment has been minimized.

Show comment Hide comment
@nkbj

nkbj Jun 9, 2013

Contributor

WIN32 is set by GCC if you remove the -ansi flag.

Best regards,
Niels Kristian Bech Jensen

Contributor

nkbj commented Jun 9, 2013

WIN32 is set by GCC if you remove the -ansi flag.

Best regards,
Niels Kristian Bech Jensen

@nkbj

This comment has been minimized.

Show comment Hide comment
@nkbj

nkbj Jun 21, 2013

Contributor

mingwrt 4.0-rc3 was released a couple of Days ago. It should solve some of the problems.

Best regards,
Niels Kristian Bech Jensen

Contributor

nkbj commented Jun 21, 2013

mingwrt 4.0-rc3 was released a couple of Days ago. It should solve some of the problems.

Best regards,
Niels Kristian Bech Jensen

@tonytheodore

This comment has been minimized.

Show comment Hide comment
@tonytheodore

tonytheodore Apr 7, 2014

Member

Superseded by #323

Member

tonytheodore commented Apr 7, 2014

Superseded by #323

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