Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
BehzadA opened this issue Sep 9, 2021 · 7 comments

Comments

@BehzadA
Copy link

BehzadA commented Sep 9, 2021

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
Copy link

mirh commented Sep 9, 2021

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

@BehzadA
Copy link
Author

BehzadA commented Sep 9, 2021

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
Copy link

arvl130 commented Sep 10, 2021

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.

@BehzadA BehzadA changed the title Three issues about Ninewinecfg that can be confusing users Three issues about Ninewinecfg that can be confusing users on RPM-based distros Sep 10, 2021
@dhewg
Copy link
Collaborator

dhewg commented Sep 10, 2021

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
Copy link
Collaborator

dhewg commented Sep 10, 2021

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
Copy link
Author

BehzadA commented Sep 10, 2021

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 BehzadA closed this as completed Sep 10, 2021
@BehzadA BehzadA reopened this Sep 10, 2021
@BehzadA
Copy link
Author

BehzadA commented Sep 10, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants