Using the gallium-nine-standalone package in Gentoo no longer works to enable gallium nine, but it works fine using the upstream repo. The problem is that Gentoo has the 0.9-nine-dll-path.patch what changes the d3d9-nine.dll.so path to "Z:${EPREFIX}/usr/$(get_libdir)/d3d9-nine.dll.so" (Using a define in the ebuild) while upstream uses a script to symlink the path in the current wineprefix. Reproducible: Always
I don't think that's the problem as it's worked this way for a long time. The symlink isn't broken. When I click the button, I see an error along with this from strace, so it seems to have something to do with ninewinecfg.exe. I'll take a closer look soon. > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe", 0x1000ff0f0, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe", 0x1000ff180, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe", 0x1000ff0f0, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe", 0x1000ff180, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe -e", <unfinished ...> > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe -e", 0x1000ff180, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe -e", 0x1000ff0f0, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe -e", 0x1000ff180, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe -e -n", 0x1000ff0f0, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe -e -n", 0x1000ff180, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe -e -n", 0x1000ff0f0, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/syswow64/ninewinecfg.exe -e -n", 0x1000ff180, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > write(2, "err:d3d9nine:executeCmdline Crea"..., 59err:d3d9nine:executeCmdline CreateProcessA failed, error=2 > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/system32/d3d9.dll", {st_mode=S_IFLNK|0777, st_size=50, ...}, AT_SYMLINK_NOFOLLOW) = 0 > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/system32/d3d9.dll", {st_mode=S_IFLNK|0777, st_size=50, ...}, AT_SYMLINK_NOFOLLOW) = 0 > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/system32/d3d9-nine.bak", {st_mode=S_IFREG|0644, st_size=190360, ...}, AT_SYMLINK_NOFOLLOW) = 0 > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/system32/d3d9-nine.bak", {st_mode=S_IFREG|0644, st_size=190360, ...}, AT_SYMLINK_NOFOLLOW) = 0 > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/system32/d3d9.dll", {st_mode=S_IFLNK|0777, st_size=50, ...}, AT_SYMLINK_NOFOLLOW) = 0 > unlink("/tmp/wine/dosdevices/c:/windows/system32/d3d9.dll") = 0 > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/z:/usr/lib64/d3d9-nine.dll.so", {st_mode=S_IFREG|0755, st_size=241480, ...}, AT_SYMLINK_NOFOLLOW) = 0 > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/z:/usr/lib64/d3d9-nine.dll.so", {st_mode=S_IFREG|0755, st_size=241480, ...}, AT_SYMLINK_NOFOLLOW) = 0 > openat(AT_FDCWD, "/tmp/wine/dosdevices/z:/usr/lib64/d3d9-nine.dll.so", O_RDONLY|O_NONBLOCK) = 90 > readlink("/usr/lib64/d3d9-nine.dll.so", 0x7ffc818e8e00, 1023) = -1 EINVAL (Invalid argument) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/z:/usr/lib64/d3d9-nine.dll.so", {st_mode=S_IFREG|0755, st_size=241480, ...}, AT_SYMLINK_NOFOLLOW) = 0 > openat(AT_FDCWD, "/tmp/wine/dosdevices/z:/usr/lib64/d3d9-nine.dll.so", O_RDONLY|O_CLOEXEC) = 11 > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/system32/d3d9.dll", 0x1000ff040, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/system32/d3d9.dll", 0x1000ff0d0, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) > symlink("/tmp/wine/dosdevices/z:/usr/lib64/d3d9-nine.dll.so", "/tmp/wine/dosdevices/c:/windows/system32/d3d9.dll") = 0 > newfstatat(AT_FDCWD, "/tmp/wine/dosdevices/c:/windows/system32/d3d9.dll", {st_mode=S_IFLNK|0777, st_size=50, ...}, AT_SYMLINK_NOFOLLOW) = 0 > readlink("/tmp/wine/dosdevices/c:/windows/system32/d3d9.dll", "/tmp/wine/dosdevices/z:/usr/lib6"..., 260) = 50
Removing the patch and using the upstream nine-install.sh script (Modified for Gentoo's expected paths) allows it to work again. I suspect something changed in wine as this also used to work for me, but its been a while since I checked.
Did you start to use USE=wow64 on wine by any chances? This changes how paths are reported by 'winepath' notably, and broke a few install scripts relying on it (e.g. vkd3d-proton's and dxvk's, not that dxvk officially ship that script anymore -- currently patched by ebuilds). Haven't really looked at nine-install.sh though.
(In reply to Ionen Wolkens from comment #3) > This changes how paths are reported by 'winepath' notably Aka, formerly "wine winepath -u 'C:\windows\system32'" and "wine64 winepath -u 'C:\windows\system32'" would return syswow64 and system32 in that order. But with USE=wow64, they will both return system32 given wine64 is just a symlink to wine, meaning syswow64 install likely goes missing and it installs twice in the same path (but it's still needed for 32bit).
For vkd3d-proton/dxvk, I just added a sanity check which requests C:\windows\syswow64 directly to winepath *if* the paths were identical for 64bit and 32bit, so it works for both. Reminder that syswow64 is for 32bit, and system32 is for 64bit despite the names :) Nevermind if didn't USE=wow64, albeit that's likely still something that need fixing.
No, I'm not using USE=wow64, my USE for wine-vanilla is: USE="X alsa crossdev-mingw fontconfig gecko gstreamer llvm-libunwind mingw mono nls opengl sdl ssl strip truetype unwind vulkan xcomposite"
(In reply to orbea from comment #6) > No, I'm not using USE=wow64, my USE for wine-vanilla is: > > USE="X alsa crossdev-mingw fontconfig gecko gstreamer llvm-libunwind mingw > mono nls opengl sdl ssl strip truetype unwind vulkan xcomposite" I see, nothing notable that I'm aware of should've changed for that setup then.
Okay, the ninewinecfg.exe stuff was a red herring. Adding that file doesn't help. Downgrading to 0.8 does, and you still get those errors. I think the real problem is https://github.com/iXit/wine-nine-standalone/commit/ecb380220283076e19a4b5c911d72ca49acdc441, but I need to double check.
Reverting that does make it work, but I don't know why yet.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1c28c05cda60c803c4ffd196861efc73d7a978bc commit 1c28c05cda60c803c4ffd196861efc73d7a978bc Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2024-02-13 22:21:48 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2024-02-13 22:21:48 +0000 app-emulation/gallium-nine-standalone: Fix ninewinecfg detection in 0.9 This was broken because it was comparing the string Z:\ against z:\. Closes: https://bugs.gentoo.org/924020 Signed-off-by: James Le Cuirot <chewi@gentoo.org> ...nine-standalone-0.9.ebuild => gallium-nine-standalone-0.9-r1.ebuild} | 2 +- .../gallium-nine-standalone/gallium-nine-standalone-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
The root cause turned out to be mildly amusing. :)
