Incompatible with Wine 10.0-1/gcc 14/Arch linux + workaround

[Anakiev2]

tldr - Enabling/Disabling Gallium nine doesn't work on Arch Linux. I've managed to fix it by replacing one string.

--- orig/src/wine-nine-standalone/ninewinecfg/main.c	2025-01-24 19:25:51.535460369 +0200
+++ fix/src/wine-nine-standalone/ninewinecfg/main.c	2025-01-24 18:59:49.152137930 +0200
@@ -257,7 +257,7 @@
         return FALSE;
 
     buf[ret] = 0;
-    return !strcmp(buf + ret - strlen(fn_nine_dll), fn_nine_dll);
+    return !strcmp(buf + ret - strlen(fn_nine_dll), "9-nine.dll.so");
 }
 
 static BOOL nine_get_system_path(CHAR *pOut, DWORD SizeOut)

Long story - ninewinecfg cannot enable or disable Gallium nine on Arch Linux with either cli or gui. Running wine ninewinecfg -e returns 1. Running wine ninewinecfg -d returns 0 but it's not disabled. With the gui the checkbox Enable Gallium Nine... cannot be checked (no matter how many times I click). There is no output in the terminal window indicating what's wrong. It's the same with the latest version from github (wine-nine 0.11-devel).

I've managed to fix the problem by replacing this line:

wine-nine-standalone/ninewinecfg/main.c

Line 260 in 909f059

return !strcmp(buf + ret - strlen(fn_nine_dll), fn_nine_dll);

with return !strcmp(buf + ret - strlen(fn_nine_dll), "9-nine.dll.so");.

I've found the "correct" string by printing some variables to stdout:

buf="/usr/lib32/wine/i386-unix/d3d9-nine.dll.so"
buf+ ret=""
buf + ret - strlen(fn_nine_dll)="9-nine.dll.so"
fn_nine_dll="d3d9-nine.dll"

After recompiling the checkbox works. Both the gui and the cli (with -e/-d) can enable/disable successfully.

Tested on:

wine 10.0-1
wine 9.22-1
wine-staging 9.22-1
wine-nine 0.10-1
linux 6.12.10.arch1-1
gcc 14.2.1+r134+gab884fffe3fc-2

[Anakiev2]

I've done some more debugging and the presents of .so in the path creates the problem. I don't know if this is Arch Linux specific issue. This is my updated "fix" to add a local variable in is_nine_symlink() with the correct filename:

--- main.c	2025-01-25 10:28:57.608751696 +0200
+++ fix.c	2025-01-25 10:28:03.692087040 +0200
@@ -247,6 +247,7 @@
 {
     ssize_t ret;
     char *fn = unix_filename(filename);
+    static const char * const fn_nine_dll = "d3d9-nine.dll.so";
     CHAR buf[MAX_PATH];
 
     if (!fn)

It works perfectly fine.

[lorn10]

To following might be not directly related to this issue here but in my case with Wine 10.1 and Kubuntu 24.04 LTS Gallium Nine v0.10.0.408 (which was installed via winetricks) works fine.

My install steps were (in regard to an upgrade from Kubuntu 22.04 LTS):

sudo dpkg --add-architecture i386

sudo apt-get install libd3dadapter9-mesa

sudo apt-get install libd3dadapter9-mesa:i386

And although Gallium Nine was already present in the wine prefix I had to enforce a reinstall via the -f parameter.

./winetricks -q -f galliumnine

After that Gallium Nine is again working.

Note, there seems to be a clear regression with the compatibility of the native d3dcompiler_47.dll file in newer Wine releases. I can confirm various crashes and hangs in conjunction with the cxbx xBox emulator. Those are not present with the built-in variant of d3dcompiler_47.dll . However, because the implementation is incomplete there are multiple graphical glitches present with the built-in file.

Probably I will open a new bug report about that at Wine's Bugzilla. 😉

[EliasTheGrandMasterOfMistakes]

I've done some more debugging and the presents of .so in the path creates the problem. I don't know if this is Arch Linux specific issue. This is my updated "fix" to add a local variable in is_nine_symlink() with the correct filename:

--- main.c 2025-01-25 10:28:57.608751696 +0200
+++ fix.c 2025-01-25 10:28:03.692087040 +0200
@@ -247,6 +247,7 @@
{
ssize_t ret;
char *fn = unix_filename(filename);

• static const char * const fn_nine_dll = "d3d9-nine.dll.so";
  CHAR buf[MAX_PATH];

  if (!fn)

It works perfectly fine.

please if are possible send it to wine-nine gitlab pkgbuild repo, actual package is broken