| Summary: | app-emulation/gallium-nine-standalone-0.9 - ninewinecfg.exe no longer works | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | orbea <orbea> |
| Component: | Current packages | Assignee: | James Le Cuirot <chewi> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | chewi, ionen, orbea, wine |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://github.com/iXit/wine-nine-standalone/issues/166 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
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. :) |
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