search

iXit / wine-nine-standalone

Build Gallium Nine support on top of an existing WINE installation
GNU Lesser General Public License v2.1
272 stars 23 forks source link

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

Open BehzadA opened 2 years ago

BehzadA commented 2 years ago

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.

mirh commented 2 years ago

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

BehzadA commented 2 years ago

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
arvl130 commented 2 years ago

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.

dhewg commented 2 years ago

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 commented 2 years ago

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

BehzadA commented 2 years ago

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 commented 2 years ago

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