Dxvk: Gentoo - can't compile, bunch of errors

[zolfone]

I'm trying to compile dxvk from source, but I get these errors when running ninja (both 32&64 bit):
https://pastebin.com/q1C6uT87

I have these packages versions:
wine-vulkan 3.3 (from roderikc's git) compiled with vulkan and 64bit support
meson 0.44.1 (portage)
migw64 5.0.3-r1 (portage)
glslang 6.2.2596 (portage)

I need it to test Rotscha's workaround here #127, but I get the errors even with a clean source tree, any help is appreciated thanks

[doitsujin]

Your mingw build does not seem to have pthread support.

[zolfone]

How do I check it? Is there a test I can do? I think I built it correctly with pthread support.

[doitsujin]

I don't know since I'm not running Gentoo, but apparently the mingw binaries with threading support have a -pthread suffix on Debian/Ubuntu systems, maybe it's the same for your setup.

[pchome]

or thread_dep = dependency('threads') from src/dxvk/meson.build don't work as expected.
For me it don't, despite description on http://mesonbuild.com/howtox.html#enable-threads and I have to use -lpthread instead but not with mingw. Can be meson notabug.

[ShadowsFriend]

I'm using Gentoo as well. The instructions listed on https://bugs.gentoo.org/631460 help to work around the issue and let me compile dxvk.

[saboya]

Any Gentoo user with an ebuild yet? Also a Gentoo user here, not sure how to write an ebuild for a different toolchain. Probably something that shouldn't be done, but... :)

[ShadowsFriend]

Be wary of using the crossdev toolchain. I've used the most recent testing[1] mingw toolchains installed by crossdev for 32 and 64 bit and they produced dlls that crashed Final Fantasy X HD without an error while the precompiled ones from https://haagch.frickel.club/files/dxvk/ do not (See #187). There seems to be something wrong with at least the 32-bit toolchain.

• gcc 7.3.0 (with pthread support manually enabled as mentioned in the comment above)
• mingw64-runtime 5.0.3-r1

[aqxa1]

I have the same problem, ShadowsFriend. When compiled with crossdev toolchain (gcc 7.3.0), The Witcher 3 crashes immediately when run. I may try the crossdev stable option to rule out problems with the more recent toolchain packages.

Since TW3 is a 64-bit game, the problem is not just limited to the 32-bit toolchain.

[ChristophHaag]

My builds just use the opensuse mingw build as described in https://haagch.frickel.club/files/dxvk/how_to_docker_build.txt

I have not updated that docker container for a while so the mingw used is maybe not the newest version.

[aqxa1]

I just tested it, and the stable crossdev toolchain (-S/--stable) fixes the problem. This is with gcc-6.4.0, binutils-2.29.1-r1, mingw64-runtime-5.0.3-r1.

[ShadowsFriend]

That indeed works. Thank you very much, thirdeyefunction! I also did a quick test with the goal to determine whether it's gcc or binutils by trying different combinations (old gcc with new binutils and vice versa). Neither of those combinations worked, which means it's both together -- unless I made a mistake.

[pchome]

Ok, I think I have working MinGW GCC 8.1 on Gentoo now.
No problems so far.

$ eix -Ic cross-*/*

[I] cross-x86_64-w64-mingw32/binutils [1] (2.29.1-r1(2.29.1)@04.04.18 2.30-r2(2.30)@02.05.18): Tools necessary to build programs
[I] cross-x86_64-w64-mingw32/gcc [1] (6.4.0-r1(6.4.0)@04.04.18 8.1.0(8.1.0)@03.05.18): The GNU Compiler Collection
[I] cross-x86_64-w64-mingw32/mingw64-runtime [1] ([email protected]): Free Win64 runtime and import library definitions

[saboya]

I'm building dxvk with GCC 7.3.0 on Gentoo, no problems. The only issue as compiling mingw with pthreads, had to modify gcc eclass.

[ShadowsFriend]

I can actually confirm that the toolchains listed below do produce working binaries. The only reason for using mingw64-runtime-5.0.3-r1 instead of r2 for x86_64 is the issue described under [1].

[1] https://bugs.gentoo.org/653246

[I] cross-i686-w64-mingw32/binutils [2] (2.30-r2(2.30)@10.05.2018)
[I] cross-i686-w64-mingw32/gcc [2] (7.3.0-r1(7.3.0)@10.05.2018)
[I] cross-i686-w64-mingw32/mingw64-runtime [2] ([email protected])

[I] cross-x86_64-w64-mingw32/binutils [2] (2.30-r2(2.30)@10.05.2018)
[I] cross-x86_64-w64-mingw32/gcc [2] (7.3.0-r1(7.3.0)@10.05.2018)
[I] cross-x86_64-w64-mingw32/mingw64-runtime [2] ([email protected])

Edit: @saboya: You actually do not even need to modify the gcc eclass. Putting an environment file containing EXTRA_ECONF="--enable-threads=posix" into /etc/portage/env/ and activating that environment file for the cross-gccs in /etc/portage/package.env also does the trick.

[saboya]

@ShadowsFriend How did you enable ptreahds support on crossdev mingw on Gentoo? I had to fork the toolchain eclass to do so.

[ShadowsFriend]

I edited my previous post containing the answer to your question while you were posting it. Because I am uncertain if mentioning someone in an edit actually does notify the person, I decided to write this post to make sure my answer reaches you.

[Wesmania]

I was able to build dxvk without issues following instructions written down here, which include setting up the cross-gcc to use posix pthreads. Can anyone else confirm that it's a fix for them as well?

[saboya]

I've been building mine just fine for like months. This issue can be closed I guess.

[ShadowsFriend]

I have skimmed over the instructions linked by you, Wesmania, and they seem to be a concise version of what I did to get it work. So I would say the link is a good source of information for fellow Gentoo users struggling to get the cross toolchain up for DXVK.

[pchome]

FYI: as an alternative you can try winelib builds ( #520 ). This don't require mingw but utilizes WINE's winegcc wrapper instead to compile sources via GCC.

[pchome]

I have created _POC_ overlay for dxvk winelib builds.

+ support both 32 and 64 bit builds (0.70 patched to current git master)

+ each version have it's own slot, so multiple versions can be installed at the same time

+ hacked `setup_dxvk.sh` to use with multi-version, e.g.:
  dxvk-setup-0.70 
  dxvk-setup-9999
  dxvk-setup-amd64-0.70
  dxvk-setup-amd64-9999
  dxvk-setup-x86-0.70
  dxvk-setup-x86-9999

- custom cflags not supported (due to meson.eclass simplicity and/or my incompetence)
  'release' build type used atm

- dirty hacks here and there in ebuild code

- own custom setup script / verb needed, existing ones are very dll/mingw specific

- not tested

This will emerge DXVK using winegcc and setup symlinks/overrides for your wine prefix:

# emerge -1 games-util/dxvk:0.70 games-util/dxvk:9999 -q

$ WINEPREFIX=/path/to/prefix dxvk-setup-9999

[edmondo]

@pchome Nice! Thanks. Emerging right now :) I'll let you know how it goes.

~ # emerge -1 games-util/dxvk:0.70 games-util/dxvk:9999 -av

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  NS    ] app-emulation/wine-vanilla-3.14:3.14::dxvk [3.7:3.7::gentoo, 3.9:3.9::gentoo, 3.10:3.10::gentoo, 3.11:3.11::gentoo] USE="X alsa cups fontconfig gecko gphoto2 jpeg lcms ldap mono mp3 ncurses nls opengl perl png pulseaudio realtime run-exes sdl ssl threads truetype udev udisks vulkan xcomposite xml -capi -custom-cflags -dos -gsm -gssapi -gstreamer -kerberos -netapi -odbc -openal -opencl -osmesa -oss -pcap -prelink -samba -scanner (-selinux) -test -v4l -vkd3d -xinerama" ABI_X86="32 64 (-x32)" 20,102 KiB
[ebuild  N     ] games-util/dxvk-0.70:0.70::dxvk  USE="-tests -utils" ABI_X86="32 (64) (-x32)" 523 KiB
[ebuild  N    *] games-util/dxvk-9999:9999::dxvk  USE="-tests -utils" ABI_X86="32 (64) (-x32)" 0 KiB

Total: 3 packages (2 new, 1 in new slot), Size of downloads: 20,624 KiB

[edmondo]

@pchome Great stuff.

~ $ WINEPREFIX=/mnt/storage/wine/64 dxvk-setup-9999
wine: configuration in '/mnt/storage/wine/64' has been updated.
[1/5] dxgi:
    [1/2] Creating override... The operation completed successfully.
    [2/2] Creating link to dxgi.dll.so... Done.
(...)
[5/5] d3d11:
    [1/2] Creating override... The operation completed successfully.
    [2/2] Creating link to d3d11.dll.so... Done.

And it's running well. But how about the tag "g4c8bf44"? I don't find the commit in the dxvk repository.

info:  DXVK: v0.70-5-g4c8bf44
warn:  OpenVR: Failed to locate module
info:  Enabled instance extensions:
info:    VK_KHR_get_physical_device_properties2
info:    VK_KHR_surface
info:    VK_KHR_win32_surface
info:  AMD RADV POLARIS10 (LLVM 8.0.0):
info:    Driver: 18.2.99
info:    Vulkan: 1.1.70

[pchome]

@edmondo

But how about the git tag "g4c8bf44"? I don't find the commit in the dxvk repository.

It's 4c8bf44 I guess. But I don't know what 5-g mean, some kind of patched version indicator.
I'm using patch from #575 for both 0.70 and 9999 for now.

EDIT: Since patch contains 5 changes (lines starting with @@), than let suppose it means 5 changes greater than 4c8bf44 :)

[edmondo]

Ah, now I slowly get it :)

It's just the output of git describe

EDIT: Something like "last tag" + number of patches + "g(it) commit"

EDIT2: From here:
https://github.com/doitsujin/dxvk/blob/0aa427d5d8efd1f22f072d700022e1dc1afa0e21/meson.build#L59

[ryao]

We really should be able to build with wineg++ rather than mingw. However, there seems to be a regression in wine that causes it to try to link the 64-bit libwinecrt0.a into the 32-bit binary. Trying to do wineg++ -m32 hello.c for example will fail:

x86_64-pc-linux-gnu-ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib64/wine-staging-3.9/wine/libwinecrt0.a(exe_entry.o)) to format elf32-i386 (a.E9mdEC.o) is not supported
winebuild: x86_64-pc-linux-gnu-ld failed with status 1
winegcc: winebuild failed

As for a 64-bit build, we hit the following:

wineg++  -o src/dxgi/dxgi.dll.so 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_adapter.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_device.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_enums.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_factory.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_format.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_main.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_options.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_output.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_presenter.cpp.o' 'src/dxgi/src@dxgi@@dxgi.dll@sha/dxgi_swapchain.cpp.o' ../src/dxgi/dxgi.spec -Wl,--no-undefined -Wl,--as-needed -Wl,-O1 -shared -fPIC -Wl,--start-group -Wl,-soname,dxgi.dll.so src/util/libutil.a src/dxvk/libdxvk.a src/spirv/libspirv.a -lwinevulkan -Wl,--end-group -m64 -mwindows 
src/dxvk/libdxvk.a(vulkan_dxvk_vulkan_loader.cpp.o): In function `dxvk::vk::DeviceLoader::DeviceLoader(VkInstance_T*, VkDevice_T*)':
dxvk_vulkan_loader.cpp:(.text+0x4d): undefined reference to `native_vkGetInstanceProcAddrWINE'
src/dxvk/libdxvk.a(vulkan_dxvk_vulkan_loader.cpp.o): In function `dxvk::vk::LibraryLoader::sym(char const*) const':
dxvk_vulkan_loader.cpp:(.text+0x3): undefined reference to `native_vkGetInstanceProcAddrWINE'
src/dxvk/libdxvk.a(vulkan_dxvk_vulkan_loader.cpp.o): In function `dxvk::vk::InstanceLoader::sym(char const*) const':
dxvk_vulkan_loader.cpp:(.text+0x25): undefined reference to `native_vkGetInstanceProcAddrWINE'
collect2: error: ld returned 1 exit status
winegcc: x86_64-pc-linux-gnu-g++ failed

If I manually fix the 32-bit build to find the correct libwinecrt0.a file, it will then hit that problem too.

I wrote a patch that will address both 32-bit and 64-bit builds. However, it relies on a path that is dependent on the version of wine that you have installed to get the 32-bit version to build, so it isn't appropriate to merge:

diff --git a/build-wine32.txt b/build-wine32.txt
index 75c4f30..a0aeac6 100644
--- a/build-wine32.txt
+++ b/build-wine32.txt
@@ -9,8 +9,8 @@ needs_exe_wrapper = true
 winelib = true

 c_args=['-m32']
-cpp_args=['-m32', '--no-gnu-unique', '-Wno-attributes']
-cpp_link_args=['-m32', '-mwindows']
+cpp_args=['-m32', '--no-gnu-unique', '-Wno-attributes', '-Dnative_vkGetInstanceProcAddrWINE=wine_vkGetInstanceProcAddr']
+cpp_link_args=['-m32', '-mwindows', '/usr/lib32/wine-staging-3.9/wine/libwinecrt0.a', '-L/usr/lib32/wine-staging-3.9']

 [host_machine]
 system = 'linux'
diff --git a/build-wine64.txt b/build-wine64.txt
index f4a69cd..316b306 100644
--- a/build-wine64.txt
+++ b/build-wine64.txt
@@ -9,7 +9,7 @@ needs_exe_wrapper = true
 winelib = true

 c_args=['-m64']
-cpp_args=['-m64', '--no-gnu-unique', '-Wno-attributes']
+cpp_args=['-m64', '--no-gnu-unique', '-Wno-attributes', '-Dnative_vkGetInstanceProcAddrWINE=wine_vkGetInstanceProcAddr']
 cpp_link_args=['-m64', '-mwindows']

 [host_machine]

Then building the 32-bit and 64-bit versions just requires the following:

cd /path/to/dxvk
meson --cross-file build-wine64.txt --prefix /tmp/dxvk64 build.w64
cd build.w64
meson configure -Dbuildtype=release
ninja
ninja install

cd /path/to/dxvk
meson --cross-file build-wine32.txt --prefix /tmp/dxvk32 build.w32
cd build.w32
meson configure -Dbuildtype=release
ninja
ninja install

I have not actually tested these to see if they work, but I have no reason to think otherwise.

[ryao]

@zolfone Did you consider at any point filing a Gentoo bug report about this or pinging one of the Gentoo developers involved with either wine or crossover downstream maintenance? If you had pinged me for instance, I probably would have helped. ;)

@doitsujin How does this even build for you? I could understand you having a version of wine installed that doesn't have the -m32 regression, but I see no way to make this build without modifying your build-wine{32,64}.txt files to change the symbol for native_vkGetInstanceProcAddrWINE.

[ryao]

@pchome I just saw your overlay. The remark on >=app-emulation/wine-*-3.14 being required saves me from figuring out how to fix wineg++.

There are a few things in the overlay that I can spot at a glance that probably should be changed:

1. I don't think you needed to fork the meson.eclass. You could have just set CC, CPP and friends in the environment.
2. Forking the eclass would have meant changing the maintainer fields. You left them as is.
3. You are supposed to provide an actual email on commits and in metadata.xml.

There is probably more, but you did this very nicely. I have spent far too much time on these things this week to do much more here, but next week, we should have a chat about getting your work merged into the main tree. :)

[pchome]

@ryao

native_vkGetInstanceProcAddrWINE

At the moment, I am still perplexed by how the thing even compiles for people because it references native_vkGetInstanceProcAddrWINE, which does not exist. I had to pass -Dnative_vkGetInstanceProcAddrWINE=wine_vkGetInstanceProcAddr to the preprocessor to make it happy.

Some clarifications:

• #583
  wine-3.14 or simply grab corresponding commit(s) from WINE git for older WINE versions
• or you hacking build system and forgot to add -lwinevulkan dependency

[doitsujin]

Is this still an issue by the way or can this be closed?

[saboya]

@pchome 's overlay has a working dxvk winelib ebuild, and you can build it fine with mingw if you compile with pthreads. I believe this can be closed.