Bug 903990 – app-emulation/wine-staging-8.5 wine64 could not load ntdll.so: undefined symbol: _ULx86_64_step with llvm-libunwind

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description tigrmango 2023-04-08 04:44:36 UTC]

I compiled the newest wine-staging-8.5 and when i try to call the resulting wine64 executable, the following error occurs:
"wine: could not load ntdll.so: /usr/bin/../lib64/wine/x86_64-unix/ntdll.so: undefined symbol: _ULx86_64_step"
This happens on both my machines, with any >=wine-staging-8.0 i think. I tried recompiling llvm-libunwind, wine-staging and llvm in different orders but nothing really helped.

[Comment 1 tigrmango 2023-04-08 04:56:04 UTC]

Created attachment 859684 [details]
Build log

[Comment 2 tigrmango 2023-04-08 04:57:32 UTC]

Created attachment 859685 [details]
emerge --info \=app-emulation/wine-staging-8.5

[Comment 3 Ionen Wolkens 2023-04-08 05:38:49 UTC]

Haven't tried exact same setup yet but can't reproduce so far (I always use llvm-libunwind as-is and my ntdll.so is linked with it, tried with both clang and gcc and wine64 works fine)

But pretty sure this is where this is going wrong:

    checking for unw_step... no
    checking for unw_step in libunwind... yes

As far as I can tell the first unw_step shouldn't be "no" when using clang (it's normal when using gcc) and this is causing it to fallback to using `-static-libgcc -lunwind` which probably doesn't quite work with this clang setup.

build64/config.log may or may not have more info

fwiw may want to try without -rtlib=compiler-rt

I use compiler-rt as well but through USE=default-compiler-rt on clang-common instead:
[ebuild   R   ] sys-devel/clang-common-16.0.1  USE="default-compiler-rt default-lld llvm-libunwind -default-libcxx -hardened -stricter -verify-sig"

[Comment 4 tigrmango 2023-04-08 07:46:25 UTC]

Created attachment 859686 [details]
emerge -pqv \=app-emulation/wine-staging-8.5

[Comment 5 tigrmango 2023-04-08 07:59:54 UTC]

Tried to compile without -rtlib=compiler-rt, nothing changed. Also, the error isn't present in wine-vanilla-8.5.

[Comment 6 tigrmango 2023-04-08 08:04:08 UTC]

Also it still does the unw_step thing in config phase

[Comment 7 Ionen Wolkens 2023-04-08 15:34:27 UTC]

Well, probably figured why the first unw_step is failing for you but it doesn't seem to be an issue (happens when USE=-default-compiler-rt on clang-common, but setting it or not doesn't seem to break wine64 either way for me -- albeit I do suggest to enable that if you're using compiler-rt anyway).

So still can't reproduce... tried to semi-copy your emerge --info by having:

    AR="llvm-ar"
    CC="clang"
    CFLAGS="-O2 -pipe -march=native -ftree-vectorize -fstack-protector-strong"
    CXX="clang++"
    CXXFLAGS="-O2 -pipe -march=native -ftree-vectorize -fstack-protector-strong"
    LDFLAGS="-Wl,-O2,--as-needed -fuse-ld=lld -rtlib=compiler-rt"
    NM="llvm-nm"
    RANLIB="llvm-ranlib"

and same USE on wine-staging:

    [ebuild   R   ] app-emulation/wine-staging-8.5  USE="X alsa cups fontconfig gecko gstreamer llvm-libunwind mingw mono nls opengl pulseaudio sdl ssl truetype udev udisks unwind usb v4l vulkan wayland xcomposite -capi -crossdev-mingw -custom-cflags -debug -dos -gphoto2 -kerberos -netapi -opencl -osmesa -pcap -perl -samba -scanner (-selinux) -smartcard -xinerama" ABI_X86="64 -32"

but staging-8.5's wine64 still works (tried a few basic things like `wine64 notepad`, and `winecfg`).

Sorry, I have no idea what may be different for you. fwiw I haven't tried with a stable system, but it worked fine there a few months ago when I last tried and wouldn't "think" it'd change anything. I also haven't tried with bashrc-mv (that you seem to be using) which sometime cause unexpected issues.

If you (or anyone else affected, but haven't got other reports so far) can't figure out the cause, may want to do USE=-unwind. Don't think I can help without some way to reproduce.

(note that using llvm-libunwind also isn't officially supported upstream, we're patching so it can build with it -- not that I've had problems regardless).