wine-nine-standalone icon indicating copy to clipboard operation
wine-nine-standalone copied to clipboard

Three issues about Ninewinecfg that can be confusing users on RPM-based distros

Open BehzadA opened this issue 2 years ago • 7 comments

I installed Wine-Nine-Standalone package on openSUSE Tumbleweed and seen these issues

1. When installing Wine-Nine through the package, a Symlink to "/lib/wine/fakedlls/ninewinecfg.exe" doesn't create, and the errors "Application could not be started, or no application associated with the specified file." and "ShellExecuteEx failed: File not found." are displayed, and must enter the full path of ninewinecfg.exe.

2. When disabling Gallium-nine, deletes the Symlink d3d9.dll(Linked to "/lib/wine/d3d9-nine.dll") in the system32 folder but doesn't create a d3d9.dll Symlink to "/lib/wine/i386-windows/d3d9.dll", and must create manually or copy the d3d9.dll to system32 folder, also the same issue exists when installing Wine-Nine through Winetricks.

3. When disabling Gallium-nine by GUI of Ninewinecfg, The message "Native Direct3D 9 v0.8.0.0-release is active." is displayed incorrectly, and when using the "-d" switch doesn't display any message.

BehzadA avatar Sep 09 '21 18:09 BehzadA

At least the first two seems related to your distro packaging, I definitively didn't have anything like that on arch.

mirh avatar Sep 09 '21 22:09 mirh

No, these issues are related to the below commands in "install.sh" because in some distros like openSUSE uses the "/lib" path instead of "/lib32" for 32bit Libs(Also the same situation exist for "/bin")```

echo "installing 32bit binaries to $DST"
ln -sf "$BASE/lib32/d3d9-nine.dll.so" "$DST/d3d9-nine.dll"
ln -sf "$BASE/bin32/ninewinecfg.exe.so" "$DST/ninewinecfg.exe

BehzadA avatar Sep 09 '21 23:09 BehzadA

Works for me on Arch as well. Not sure what you mean by using /lib vs /lib32. The release tarballs don't link to anything in /lib or /lib32 of the host system.

arvl130 avatar Sep 10 '21 01:09 arvl130

The lib32/bin32 paths come from release.sh. That script builds 32 and 64bit binaries and adds nine-install.sh to easily install the built binaries from those paths. No system lib/lib32/lib64 paths are involved here.

Sounds like a suse specific packaging issue. If that package build uses different paths than release.sh it needs to patch nine-install.sh as well to reflect that.

Try a release build from here, that won't have the issue: https://github.com/iXit/wine-nine-standalone/releases

dhewg avatar Sep 10 '21 03:09 dhewg

Hm, nope, it looks like nine-install.sh isn't part of that rpm: https://build.opensuse.org/package/view_file/openSUSE:Factory/wine-nine-standalone/wine-nine-standalone.spec?expand=1 Are you mixing release tarballs from here (maybe over wintricks?) with that rpm? That probably won't work

dhewg avatar Sep 10 '21 03:09 dhewg

The lib32/bin32 paths come from release.sh. That script builds 32 and 64bit binaries and adds nine-install.sh to easily install the built binaries from those paths. No system lib/lib32/lib64 paths are involved here.

Sounds like a suse specific packaging issue. If that package build uses different paths than release.sh it needs to patch nine-install.sh as well to reflect that.

Try a release build from here, that won't have the issue: https://github.com/iXit/wine-nine-standalone/releases

If I understood correctly seem it the reason for the problem is that the Wine-Nine uses "/bin32", "/lib64", "/bin32", "/bin64" paths by default(I'm not sure), but only the "/bin" path exists on openSUSE("/bin32" or "/bin64" paths doesn't exist at all) and uses the "/lib" path instead of "/lib32"("/lib32 doesn't exist at all) for 32bit Libs(And Fedora probably has the same situation) and for managing this situation on openSUSE, Wine-Nine files paths changes to the below paths

/usr/lib64/wine /usr/lib64/wine/d3d9-nine.dll.so /usr/lib64/wine/fakedlls /usr/lib64/wine/fakedlls/d3d9-nine.dll /usr/lib64/wine/fakedlls/ninewinecfg.exe /usr/lib64/wine/ninewinecfg.exe.so /usr/share/doc/packages/wine-nine-standalone /usr/share/doc/packages/wine-nine-standalone/README.rst /usr/share/licenses/wine-nine-standalone /usr/share/licenses/wine-nine-standalone/LICENSE

/usr/lib/wine /usr/lib/wine/d3d9-nine.dll.so /usr/lib/wine/fakedlls /usr/lib/wine/fakedlls/d3d9-nine.dll /usr/lib/wine/fakedlls/ninewinecfg.exe /usr/lib/wine/ninewinecfg.exe.so

BehzadA avatar Sep 10 '21 04:09 BehzadA

Hm, nope, it looks like nine-install.sh isn't part of that rpm: https://build.opensuse.org/package/view_file/openSUSE:Factory/wine-nine-standalone/wine-nine-standalone.spec?expand=1 Are you mixing release tarballs from here (maybe over wintricks?) with that rpm? That probably won't work

In current Prefix no, but in the previous Prefix, I installed Wine-Nine through both RPM and Winetricks, and I could use both of them separately and do worked, but the same issue existed on both of them when disabling G-Nine

BehzadA avatar Sep 10 '21 04:09 BehzadA