protonscr

Winelib build fails: undefined reference to `native_vkGetInstanceProcAddrWINE'

dxvkclosed
doitsujin/dxvk#583 · opened 2018-08-21 by gasinvein · updated 2018-08-27 · 9 comments · github
Ggasinvein 2018-08-21 github

Before #520 winelib builds used to work fine.
Fedora 28, wine-staging 3.13

[  148s] [110/177] 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 -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 
[  148s] FAILED: src/dxgi/dxgi.dll.so 
[  148s] 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 -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 
[  148s] src/dxvk/libdxvk.a(vulkan_dxvk_vulkan_loader.cpp.o): In function `dxvk::vk::DeviceLoader::DeviceLoader(VkInstance_T*, VkDevice_T*)':
[  148s] /home/abuild/rpmbuild/BUILD/dxvk-0.70.5.git20180818/x86_64-redhat-linux-gnu/../src/dxvk/vulkan/dxvk_vulkan_loader.cpp:33: undefined reference to `native_vkGetInstanceProcAddrWINE'
[  148s] src/dxvk/libdxvk.a(vulkan_dxvk_vulkan_loader.cpp.o): In function `dxvk::vk::LibraryLoader::sym(char const*) const':
[  148s] /home/abuild/rpmbuild/BUILD/dxvk-0.70.5.git20180818/x86_64-redhat-linux-gnu/../src/dxvk/vulkan/dxvk_vulkan_loader.cpp:18: undefined reference to `native_vkGetInstanceProcAddrWINE'
[  148s] src/dxvk/libdxvk.a(vulkan_dxvk_vulkan_loader.cpp.o): In function `dxvk::vk::InstanceLoader::sym(char const*) const':
[  148s] /home/abuild/rpmbuild/BUILD/dxvk-0.70.5.git20180818/x86_64-redhat-linux-gnu/../src/dxvk/vulkan/dxvk_vulkan_loader.cpp:27: undefined reference to `native_vkGetInstanceProcAddrWINE'
[  148s] collect2: error: ld returned 1 exit status
[  148s] winegcc: g++ failed
[  148s] ninja: build stopped: subcommand failed.
Ddoitsujin maintainer 2018-08-21 github

You need wine 3.14.

Ggasinvein 2018-08-21 github

Ah, thanks. Maybe this should be stated in readme? It currently says

wine 3.10 or newer

Ddoitsujin maintainer 2018-08-21 github

The mingw builds work perfectly fine with 3.10, and the winelib builds are currently somewhat inofficial. There were also reports about the 32-bit winelib builds being highly unstable compared to the mingw builds.

?ghost 2018-08-27 github

Where can I find more details about those reports?

Ppchome 2018-08-27 github

@jacekcw
I noticed unstable behaviour with d3d10 "dlls" once, currently beeng built with d3d11_dep https://github.com/doitsujin/dxvk/blob/master/src/d3d10/meson.build#L9

Now I'm using lib_d3d11 instead and can't say there is other problems (compared to the mingw builds) since 32 bit patches introduced.
But I have tested a few 32 bit games/apps only, and can't say there is no problems at all.

https://github.com/doitsujin/dxvk/issues/567#issuecomment-413326698 - this happen for both winelib and mingw builds.

?ghost 2018-08-27 github

It seems to me that using lib_d3d11 would be the right thing to do. Are you planning to upstream that?

Ppchome 2018-08-27 github

I have already mentioned this several times, this change was present in my hint https://github.com/doitsujin/dxvk/issues/424#issuecomment-412335146 , and then in d3d10 branch.
But was changed then, I'm not sure for what reason, so leaving this for you and @doitsujin .

Ddoitsujin maintainer 2018-08-27 github

Building with lib_d3d11 breaks 32-bit mingw builds because it fails to find D3D11CoreCreateDevice for some reason.

Ppchome 2018-08-27 github

Then possible solution can be something like

d3d10_deps = [ lib_d3dcompiler_43, lib_dxgi ]
d3d10_deps += meson.get_cross_property('winelib', false) ? lib_d3d11 : d3d11_dep

and using d3d10_deps in dependencies.

Edit: tested this and created PR https://github.com/doitsujin/dxvk/pull/608

Upstream links

DLLs