Given that is_nine_symlink reads the symlink file d3d9.dll and compares the returned target with the hard-coded string d3d9-nine.dll, shouldn't the function nine_set call create_symlink to let d3d9.dll directly target d3d9-nine.dll instead of targetting the dli_fname of d3d9-nine.dll?
For the install carried out using nine-install.sh, d3d9.dll is a symlink targetting d3d9-nine.dll, which in turn is another symlink targetting d3d9-nine.dll.so. In such a setup, dli_fname of d3d9-nine.dll is the same - d3d9-nine.dll.
But when installed using wine-nine package of Arch Linux, d3d9-nine.dll isn't a symlink but a fake-dll d3d9-nine.dll.fake renamed to d3d9-nine.dll. For such a setup, the dli_fname of d3d9-nine.dll is d3d9-nine.dll.so. Arch's install seems to follow the same division for this wine dll as it does for other wine dlls/exes - the fake dll gets inserted into a dir i686-windows while the corresponding so gets installed into a dir i686-unix. The pairs aren't linked through a symlink, as assumed by nine.
But this setup breaks the assumption, made by is_nine_symlink, that d3d9.dll targets d3d9-nine.dll. Here, d3d9.dll targets d3d9-nine.dll.so.
If nineassumes that absolutely needs d3d9.dll symlink must to target d3d9-nine.dll (given the behaviours of is_nine_symlink and nine-install.sh), can it not call create_symlink directly for the d3d9-nine.dll instead of passing through dli_fname?
The issue that this breakage causes is that in the nine's UI, the "Enable Gallium Nine for better..." check-box remains unchecked, and cannot be checked even after clicking. Once nine is enabled through the cmdline ninewinecfg, it cannot be disabled, either through the command-line or through the GUI. These symptoms are the result of is_nine_symlink returning false.
After installing Arch's wine-nine and enabling it with ninewinecfg, one can manually retarget the d3d9.dll symlink to point to /....../i686-windows/d3d9-nine.dll, and the GUI checkbox shows nine as Enabled. The disabling of nine also works. That is, is_nine_symlink starts working as the target is now the same as the expected, hard-coded string d3d9-nine.dll.
Given that
is_nine_symlinkreads the symlink filed3d9.dlland compares the returned target with the hard-coded stringd3d9-nine.dll, shouldn't the functionnine_setcallcreate_symlinkto letd3d9.dlldirectly targetd3d9-nine.dllinstead of targetting the dli_fname ofd3d9-nine.dll?For the install carried out using
nine-install.sh,d3d9.dllis a symlink targettingd3d9-nine.dll, which in turn is another symlink targettingd3d9-nine.dll.so. In such a setup, dli_fname ofd3d9-nine.dllis the same -d3d9-nine.dll.But when installed using
wine-ninepackage of Arch Linux,d3d9-nine.dllisn't a symlink but a fake-dlld3d9-nine.dll.fakerenamed tod3d9-nine.dll. For such a setup, the dli_fname ofd3d9-nine.dllisd3d9-nine.dll.so. Arch's install seems to follow the same division for this wine dll as it does for other wine dlls/exes - the fake dll gets inserted into a diri686-windowswhile the correspondingsogets installed into a diri686-unix. The pairs aren't linked through a symlink, as assumed bynine.But this setup breaks the assumption, made by
is_nine_symlink, thatd3d9.dlltargetsd3d9-nine.dll. Here,d3d9.dlltargetsd3d9-nine.dll.so.If
nineassumes thatabsolutely needsd3d9.dllsymlinkmustto targetd3d9-nine.dll(given the behaviours ofis_nine_symlinkandnine-install.sh), can it not callcreate_symlinkdirectly for thed3d9-nine.dllinstead of passing through dli_fname?The issue that this breakage causes is that in the
nine's UI, the "Enable Gallium Nine for better..." check-box remains unchecked, and cannot be checked even after clicking. Oncenineis enabled through the cmdlineninewinecfg, it cannot be disabled, either through the command-line or through the GUI. These symptoms are the result ofis_nine_symlinkreturning false.After installing Arch's
wine-nineand enabling it withninewinecfg, one can manually retarget thed3d9.dllsymlink to point to/....../i686-windows/d3d9-nine.dll, and the GUI checkbox showsnineas Enabled. The disabling ofninealso works. That is,is_nine_symlinkstarts working as the target is now the same as the expected, hard-coded stringd3d9-nine.dll.