protonscr

arch linux/mingw64 compilation fails

dxvkclosed build
doitsujin/dxvk#173 · opened 2018-03-17 by dennisbusch-de · updated 2018-10-15 · 17 comments · github
Ddennisbusch-de 2018-03-17 github

in file:
https://github.com/doitsujin/dxvk/blob/master/src/d3d11/d3d11_include.h

in line 27: Needs to be ifdef instead of ifndef to successfully compile with mingw64 under ArchLinux, otherwise compilation fails with errors about redefinition of the symbols inside that preprocessor conditional block (edit: that's not a proper fix though, see below, the real issue being mingw headers which already include those definitions, so the workaround is outdated for those newer mingw headers)

Ddoitsujin maintainer 2018-03-17 github

Which mingw version are you using? I'm on Arch as well and the definitions are required for it to work with MinGW.

Sssorgatem 2018-03-17 github

How are you building DXVK?

Literally just built from my dxvk-git AUR package and it builds fine.

Ddennisbusch-de 2018-03-17 github

which mingw version?
[dennis@DB2arch ~]$ pacman -Q | grep mingw
mingw-w64-binutils 2.29-1
mingw-w64-crt-git 5.0.3.20180316-1
mingw-w64-gcc 7.3.0-1
mingw-w64-headers-git 5.0.3.20180316-1
mingw-w64-winpthreads-git 5.0.3.20180316-1

how I built?
I git cloned https://github.com/doitsujin/dxvk and then followed the instructions on that page. After the small change to that source file, compilation succeeded. Even tested it with Witcher3 and Kingdom Come: Deliverance which both seemed to work without issues.

"_MSC_VER" suggests it is not defined in any compiler other than Microsoft's so I am confused how those definitions should be required for mingw. Will I encounter runtime issues if I leave them out?

edit: Scratch that. I suppose I already have those definitions in my headers, so that workaround is not needed and so for me, compilation complains about redefinition, so ifdef instead of ifndef is not even a proper fix here.

Sssorgatem 2018-03-17 github

My setup is:

adria@Aegon ~ $ pacman -Q | grep mingw
mingw-w64-binutils 2.29-1
mingw-w64-configure 0.1-1
mingw-w64-crt 5.0.3-1
mingw-w64-gcc 7.3.0-1
mingw-w64-headers 5.0.3-1
mingw-w64-pkg-config 2-3
mingw-w64-winpthreads 5.0.3-1

I see you are using git headers. Maybe there's the issue?

Do you find the same problem if you try to build the dxvk-git AUR package?

Ddennisbusch-de 2018-03-17 github

See my edit. The real issue is that those definitions are already in the headers I'm using, so a proper fix would involve checking each "missing" definition (due to outdated mingw headers) individually, instead of relying on _MSC_VER and by that making assumptions of what is and what is not defined already.

Ddoitsujin maintainer 2018-03-17 github

How is that supposed to work? It is not possible to use #ifdef with typedefs, so we basically have to make assumptions about the compiler.

Also, the definitions are not missing from MinGW headers, they are not recognized (at least when using GCC 7.2). I copied them from the MinGW headers. Please don't ask me why that is necessary though.

Ddennisbusch-de 2018-03-17 github

Good question. Probably involves testing against specific mingw(headers) version then instead of testing for the absence of the Microsoft compiler version. Or maybe it is somehow possible to run a short test compilation before the real build process and conditionally include a different header if that test fails with redefinition errors?

Apparently in the (newer) headers, the definitions are recognized, otherwise the compiler would not complain about redefinition.

Example output if I don't strip the (re)definitions from the file that comes with dxvk:
[dennis@DB2arch build.w64]$ ninja [1/31] Compiling C++ object 'src/util/util@sta/com_com_guid.cpp.obj'. FAILED: src/util/util@sta/com_com_guid.cpp.obj /usr/bin/x86_64-w64-mingw32-g++ -Og -gdwarf-2 -Isrc/util/util@sta -Isrc/util -I../src/util -I.././include -fdiagnostics-color=always -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++1z -O3 -MD -MQ 'src/util/util@sta/com_com_guid.cpp.obj' -MF 'src/util/util@sta/com_com_guid.cpp.obj.d' -o 'src/util/util@sta/com_com_guid.cpp.obj' -c ../src/util/com/com_guid.cpp In file included from ../src/util/com/../../d3d11/d3d11_interfaces.h:3:0, from ../src/util/com/com_guid.cpp:3: ../src/util/com/../../d3d11/d3d11_include.h:28:16: error: redefinition of ‘struct D3D11_FEATURE_DATA_THREADING’ typedef struct D3D11_FEATURE_DATA_THREADING { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/x86_64-w64-mingw32/include/d3d11_1.h:98:0, from ../src/util/com/../../d3d11/d3d11_include.h:5, from ../src/util/com/../../d3d11/d3d11_interfaces.h:3, from ../src/util/com/com_guid.cpp:3: /usr/x86_64-w64-mingw32/include/d3d11.h:1042:16: note: previous definition of ‘struct D3D11_FEATURE_DATA_THREADING’ typedef struct D3D11_FEATURE_DATA_THREADING {

If it is all too much trouble however, we might just forget about this issue for the moment though since I can successfully compile if I just leave out those (re)defs.

Sssorgatem 2018-03-17 github

I can reproduce the issue by using the -git headers.

Is it even possible to check for the header version?

Ddoitsujin maintainer 2018-03-17 github

Or maybe it is somehow possible to run a short test compilation before the real build process and conditionally include a different header if that test fails with redefinition errors?

That sounds like complete overkill for a problem that shouldn't exist in the first place. Apparently it works with up-to-date mingw - still building the latest version, will test later.

Ddennisbusch-de 2018-03-17 github

I searched a bit but could not find a way to check for header versions alone, only found the usual compiler version defs but those likely won't be sufficient and I agree that implementing a pre-compilation test would be too much since the original issue is resolved with later headers.

Also looked at the d3d11.h file from the master branch and from the (old) 5.0.3 branch which appear to be different. The old one I see does for example not define D3D11_FEATURE_DATA_THREADING (among many others).

(5.0.3: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/v5.0.3/tree/mingw-w64-headers/direct-x/include/d3d11.h )
(master: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/direct-x/include/d3d11.h )

A pre-compilation test could involve parsing the first line:
/*** Autogenerated by WIDL 3.1 from direct-x/include/d3d11.idl - Do not edit ***/
vs.
/*** Autogenerated by WIDL 1.6 from direct-x/include/d3d11.idl - Do not edit ***/

But anyway, if the latest headers make the _MSC_VER workaround obsolete, it should just be stripped instead of making any attempt to support outdated mingw headers.

Sorry to cause any trouble. I really like this project and hope that it will be included in a future version of Wine as an optional install-time choice to replace the default Wine D3D11 implementation.

Ddoitsujin maintainer 2018-03-17 github

Think is, by removing the workaround I'd break Ubuntu 17.10 again, and the non-git Arch packages. I'll more than happily do that if Ubuntu 18.04 actually ships with updated headers, but right now this would just annoy people.

Ddennisbusch-de 2018-03-17 github

Yeah, not worth the trouble for the time being then. And the issue is not too hard to fix locally.

MMixaill 2018-03-17 github

CMake has CheckTypeSize() function to detect if structure is defined. Is meson has something similar?

Ppchome 2018-03-17 github

CMake has CheckTypeSize() function to detect if structure is defined. Is meson has something similar?

has_type(typename) ?

edit: but something like #ifdef __MINGW32__ would be better IMHO
edit2: https://sourceforge.net/p/predef/wiki/Compilers/#mingw-and-mingw-w64 - and check version if definitions not needed for current mingw-git

MMixaill 2018-03-17 github

The main problem is that headers are in w32-headers package which version is not equal to MinGW/GCC version.

has_type(typename)

more like has_header_symbol() but it crashes on my PC :D

GGloriousEggroll 2018-03-18 github

I'm on arch and am able to compile 64 and 32 bit fine (not running mingw-git). Here's my mingw packages (from AUR i believe.) for future reference to others.

[gloriouseggroll@shittywok dxvk]$ pacman -Qs mingw
local/mingw-w64-binutils 2.29-1 (mingw-w64-toolchain mingw-w64)
Cross binutils for the MinGW-w64 cross-compiler
local/mingw-w64-crt 5.0.3-1 (mingw-w64-toolchain mingw-w64)
MinGW-w64 CRT for Windows
local/mingw-w64-gcc 7.3.0-1 (mingw-w64-toolchain mingw-w64)
Cross GCC for the MinGW-w64 cross-compiler
local/mingw-w64-headers 5.0.3-1 (mingw-w64-toolchain mingw-w64)
MinGW-w64 headers for Windows
local/mingw-w64-winpthreads 5.0.3-1 (m

I believe installing the mingw-w64-gcc package should work and installs the rest

Ddoitsujin maintainer 2018-10-15 github

Should no longer be an issue when using MinGW 6.0.

Nothing extracted yet.