winelib build: undefined reference to `pthread_cond_clockwait' in dxvk::DxgiAdapter::runEventThread()

[frantisekz]

Hi,

since 1.6.1, winelib build is crashing with:

FAILED: src/dxgi/dxgi.dll.so 
wineg++  -o src/dxgi/dxgi.dll.so 'src/dxgi/cde8a16@@dxgi.dll@sha/version.res' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_adapter.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_enums.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_factory.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_format.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_main.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_monitor.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_options.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_output.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_swapchain.cpp.o' ../src/dxgi/dxgi.spec -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group -Wl,-soname,dxgi.dll.so -m64 -mwindows src/dxvk/libdxvk.a src/util/libutil.a src/spirv/libspirv.a src/vulkan/libvkcommon.a -pthread -ldl -lwinevulkan -Wl,--end-group '-Wl,-rpath,$ORIGIN/../dxvk:$ORIGIN/../util:$ORIGIN/../spirv:$ORIGIN/../vulkan' -Wl,-rpath-link,/builddir/build/BUILD/dxvk-1.6.1/x86_64-redhat-linux-gnu/src/dxvk -Wl,-rpath-link,/builddir/build/BUILD/dxvk-1.6.1/x86_64-redhat-linux-gnu/src/util -Wl,-rpath-link,/builddir/build/BUILD/dxvk-1.6.1/x86_64-redhat-linux-gnu/src/spirv -Wl,-rpath-link,/builddir/build/BUILD/dxvk-1.6.1/x86_64-redhat-linux-gnu/src/vulkan
/usr/bin/ld: src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_adapter.cpp.o: in function `dxvk::DxgiAdapter::runEventThread()':
dxgi_adapter.cpp:(.text+0x26ca): undefined reference to `pthread_cond_clockwait'
collect2: error: ld returned 1 exit status
winegcc: /usr/bin/g++ failed

Complete build log: https://kojipkgs.fedoraproject.org//work/tasks/2826/43562826/build.log
Wine used for build: wine-5.6

Thanks!

[doitsujin]

Works fine here. Please make sure that your glibc is reasonably up to date.

That said, I will remove winelib support now. This has been unmaintained for a while, and I'm really starting to get sick of the constant issues with it. You'll still be able to build DXVK using mingw.

[frantisekz]

Hmm, I have pretty recent glibc (glibc-2.31), don't know what's causing the issues, might be Fedora specific .

The reason why I was using winelib build is for dxvk packaging reasons (as wine has dxgi as a so file, only others d3dxx... are dlls) and the package is replacing wine's libraries by dxvk versions. So, I had to use winebuild to get dxvk's dxgi built as an so file.

Anyhow, thanks!

[doitsujin]

It is not necessarily a good idea to forcefully replace wine's dxgi with ours. There might still be a couple of D3D11 apps that require it, but in general, DXVK works without it on Linux these days (just with the d3d10core/d3d11 overrides), and using wine's DXGI also opens up the option to use vkd3d which is going to become increasingly important.

[TheGreatMcPain]

@frantisekz 1.6.1 winelib builds fine here on Gentoo, so it might be something on your end.
My glibc is 2.29-r7 while glibc 2.31 is not even in testing yet.

[stefson]

@TheGreatMcPain 1.6.1 winelib fails to build here with gentoo, with glibc-2.29-r8

if you can find the time, and for the sake of the argument, can you try again with glibc-2.29-r8 or glibc-2.30-r8? it might be you found a bug in the patchset

[TheGreatMcPain]

@stefson Unfortunately, my system has already updated to glibc-2.30-r8, so I won't be able to test glibc-2.29-r8 without breaking gcc, but winelib dxvk builds just fine with glibc-2.30-r8.

I also have binutils-2.33.1-r1, gcc-9.3.0, and wine-staging-5.6.

I forgot to mention I am using my own ebuild that adds `-fpermissive' to the C(XX)FLAGS, so I wonder if adding that would make it build.

EDIT: It still builds even without '-fpermissive'.

[FireBurn]

Think stopped compiling for me here with GCC 10.1.0

FAILED: src/dxgi/dxgi.dll.so
wineg++ -o src/dxgi/dxgi.dll.so 'src/dxgi/cde8a16@@dxgi.dll@sha/version.res' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_adapter.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_enums.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_factory.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_format.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_main.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_monitor.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_options.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_output.cpp.o' 'src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_swapchain.cpp.o' ../dxvk-1.6.1/src/dxgi/dxgi.spec -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,dxgi.dll.so -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -m32 -mwindows -pthread src/dxvk/libdxvk.a src/util/libutil.a src/spirv/libspirv.a src/vulkan/libvkcommon.a -ldl -lwinevulkan -Wl,--end-group '-Wl,-rpath,$ORIGIN/../dxvk:$ORIGIN/../util:$ORIGIN/../spirv:$ORIGIN/../vulkan' -Wl,-rpath-link,/var/tmp/portage/app-emulation/dxvk-1.6.1/work/dxvk-1.6.1-abi_x86_32.x86/src/dxvk -Wl,-rpath-link,/var/tmp/portage/app-emulation/dxvk-1.6.1/work/dxvk-1.6.1-abi_x86_32.x86/src/util -Wl,-rpath-link,/var/tmp/portage/app-emulation/dxvk-1.6.1/work/dxvk-1.6.1-abi_x86_32.x86/src/spirv -Wl,-rpath-link,/var/tmp/portage/app-emulation/dxvk-1.6.1/work/dxvk-1.6.1-abi_x86_32.x86/src/vulkan
src/dxgi/cde8a16@@dxgi.dll@sha/dxgi_adapter.cpp.o:dxgi_adapter.cpp:function dxvk::DxgiAdapter::runEventThread(): error: undefined reference to 'pthread_cond_clockwait'

I'll try figuring it out and update my overlay, I realise winelib builds have been dropped now

[FireBurn]

Adding -lpthread to the linker flags got things working for me, I've updated the ebuild in the Gentoo FireBurn Overlay

[Joshua-Ashton]

We don't support winelib builds anymore.

[stefson]

Yeah, we're just exchanging informations between fellow gentoo users here ;-)

I've been using ebuild from tastytea, it has now x86_64-w64-mingw32 support added and a fallback to dxvk-1.6 if it doesn't work for the user.

[Joshua-Ashton]

Please don't fall back to older versions implicitly because then we get bug reports for things that have already been fixed and it's really annoying.

Plus we never supported winelib builds anyway and those come with their own funny quirks and issues.

[TheGreatMcPain]

@stefson Did you mean that the user would have to manually fallback to 1.6.1?

It would be really strange if a 9999 ebuild automatically used an older commit without the user knowing.

[stefson]

no, it isn't pinned back, but it's ported to use mingw32 from v1.6.1 on, leaving v1.6 as is for everyone who doesn't feel the pressure to spend a lot of cpu time for bootstraping into a whole new toolchain.

[FireBurn]

I couldn't get crossdev to bootstrap

[tastytea]

The (unofficial) Gentoo repository “tastytea” has the versions 1.6 with winegcc support, 1.6.1 with mingw and optional winegcc support (broken for some) and 1.7 and 9999 without winegcc support.

The (official) repository “guru” has the package app-emulation/dxvk-bin, which installs the binaries provided by this project (No need to build a toolchain yourself).

[FireBurn]

I've got winelib 1.7 working in the (unofficial) FireBurn overlay both the commit and the ebuilds say they're unsupported and not to raise issues here

@tastytea if you wouldn't mind letting me know how you got crossdev working I'd be appreciative (gcc stage 2 keeps failing here with missing symbols)

[tastytea]

@FireBurn I did what is described in the wiki article.

[FireBurn]

Me too

…

On Sat, 16 May 2020, 20:10 tastytea, ***@***.***> wrote: @FireBurn <https://github.com/FireBurn> I did what is described in the wiki article <https://wiki.gentoo.org/index.php?title=DXVK&oldid=868682#From_source>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1584 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVD4Y73GX2WDFXWOKHC6DRR3QJDANCNFSM4MMQFD3Q> .

[TheGreatMcPain]

@FireBurn Could you provide some build logs?

I'll also go ahead and redo my crossdev toolchain to see if I also get any issues.

EDIT: I'm able to completely remove, and rebuild the mingw toolchain without to much issue using the guide on wiki article.

I only needed to separate that single emerge command from the wiki into two emerge commands, so that mingw64-runtime re-merges before gcc does. I have --jobs=4 set in my EMERGE_DEFAULT_OPTS, so running it as a single emerge command like in the wiki causes gcc to start building before mingw64-runtime can provide the libraries for pthread.

[aqxa1]

I can't it getting working either. I have been able to get it working in the past, but the whole process is unmaintainable until Gentoo provides a crossdev version that uses pthreads by default (or upstream makes pthreads the default). Otherwise, it will continue to be unreliable. See: https://bugs.gentoo.org/665512

[TheGreatMcPain]

@aqxa1 Could you send some build logs, and when does it fail for you?

[stefson]

it's a bit tricky to bootstrap the toolchain, but as of now everyone should be able to go for crossdev -S x86_64-w64-mingw32 , where any useflag of cross-x86_64-w64-mingw32/mingw64-runtime should be flipped:

emerge -pv cross-x86_64-w64-mingw32/binutils cross-x86_64-w64-mingw32/gcc cross-x86_64-w64-mingw32/mingw64-runtime

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

Calculating dependencies... done!
[ebuild   R    ] cross-x86_64-w64-mingw32/binutils-2.33.1-r1:2.33::own  USE="gold nls plugins -default-gold -doc -multitarget -static-libs -test" 0 KiB
[ebuild   R   ~] cross-x86_64-w64-mingw32/mingw64-runtime-7.0.0-r1::own  USE="-idl -libraries -tools -headers-only" 0 KiB
[ebuild   R    ] cross-x86_64-w64-mingw32/gcc-9.3.0:9.3.0::own  USE="cxx fortran libssp nls nptl openmp pch ssp -ada (-altivec) -d -debug -doc (-fixed-point) -go -graphite -hardened -jit -lto -multilib -objc -objc++ -objc-gc -pgo -pie -sanitize -systemtap -test -vanilla -vtv" 0 KiB

the toolchain has to be rebuilt then, with USE="+libraries" for cross-x86_64-w64-mingw32/mingw64-runtime, this enables pthread stuff I believe.

and finally cross-x86_64-w64-mingw32/gcc has to be rebuilt to enable posix threading instead of the default, this is done via EXTRA_ECONF="--enable-threads=posix" emerge -av --oneshot cross-x86_64-w64-mingw32/gcc

[FireBurn]

Here's the pastebin:

https://pastebin.com/ktQRx9S1

[stefson]

crossdev -S x86_64-w64-mingw32 means to use stable keywords, also I gave you all the information about which individal version of cross-binutils, mingw64-runtime and cross-gcc to use. So why don't you follow that recipe?
Also that binutils-2.34 is broken, please don't use it before it's fixed (#1625)

[FireBurn]

@stefson I was responding to the @TheGreatMcPain, I'm trying you suggestion now though it appears -S isn't picking the stable versions, also there wasn't anything in the guide about requiring that, or about binutils-2.34 being broken

I'll let you know how I get on

[stefson]

well, if you failed with current = unstable versions you must be sure to reconfigure the overlay and all the config files in /etc/portage/ for using stable keywords. crossdev process to intiate these is a bit of a mess, I've always deleted the folders in the local overlay and all the config files in /etc/portage to be sure.

--binutils --libc and --gcc crossdev switches are your friend if you're uncertain

[FireBurn]

I've forced the lower versions and I get the same issue, I've used the exact same flags as you, I've tried unsetting my flags, switching to ld.bfd as default in the host environment, just to check that wasn't causing issues either

So I've figured it out

In my /etc/portage/make.conf I had this set:

AR="gcc-ar"
NM="gcc-nm"
RANLIB="gcc-ranlib"

[FireBurn]

@tastytea I've updated my ebuilds based on yours, I did notice you weren't using the CFLAGS or CXXFLAGS not sure of this was deliberate or not. I've got dxvk working finally with lto and tested with gcc 10.1 and a patched binutils 2.34

[tastytea]

@FireBurn My ebuilds do use *FLAGS: L45 & L113.

I think we should talk elsewhere about ebuilds and issues with crossdev on Gentoo, maybe the forums or the gentoo-user mailinglist? It's a bit off-topic here. 🙂

[FireBurn]

@tastytea wherever you'd like

Take a look at https://schlomp.space/tastytea/overlay/src/branch/master/app-emulation/dxvk/files/9999-add_compiler_flags.patch#L38

That's just linker flags...

[TheGreatMcPain]

@FireBurn It looks like the patch is applying CFLAGS.

https://schlomp.space/tastytea/overlay/src/branch/master/app-emulation/dxvk/files/9999-add_compiler_flags.patch#L24

Nevermind it is only applying for win32.