Wine & Nvidia : "Patching" is not solving the problem anymore ?

FreeBSD/amd64 11.2
FreeBSD/i386 11.2 (chrooted)
nvidia-driver 390.77 (both 64-bits & 32-bits)

Hello !

So I was using FreeBSD since half a year now and my hard drive decided to suddently die. I put a new hard drive, reinstalled FreeBSD.

I never install wine from repositories, I build it myself and it always worked (not perfectly but that's another thing) until now.

I've chrooted into a FreeBSD/i386 to install a full FreeBSD with every necessary packages and I built Wine from there. It built.
I removed the libGL.so.1 symlink to create a new symlink to libGL-NVIDIA.so.1 as I always did.
I prepared a prefix, Wine is working, I can set it. I install a game from GOG. Now, time to run the game and call for 3D acceleration !

When I try to run it, how surprised I am to see this :

Code:
0009:fixme:ddraw:DirectDrawEnumerateExA flags 0x00000006 not handled
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  208
  Current serial number in output stream:  209

It's the problem you see when you don't create the symlink ! So now I've spent 3 hours trying everything I can to fix this but impossible.

And, just to try, according to the patch-nvidia.sh (this one https://svnweb.freebsd.org/ports/head/emulators/i386-wine-devel/files/nvidia.sh?view=co) I download the nvidia driver manually, extracted the libGL.so.1 to paste it to my $CHROOT/usr/local/lib but the message is exactly the same. What can be wrong ? :-( Or am I forgetting an important point ?

NOTE : $CHROOT/usr/local/lib and NOT $CHROOT/usr/local/lib32 as the script says because it is chrooted, the 32-bits libs are in "lib", there isn't any lib32 folder.

If I'm forgetting anything, please let me know. Thank you guys !
 
I readelf -a the libGL-NVIDIA.so.1 :

Code:
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            FreeBSD
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Intel i386
  Version:                           0x1
  Entry point address:               0x47a90
  Start of program headers:          52 (bytes into file)
  Start of section headers:          1015952 (bytes into file)
  Flags:                             0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         18
  Section header string table index: 17
 
No, that's an unrelated issue. Your problem is that the 375.66 libGL.so is not supposed to be used with the 390.77 driver.

...
I never install wine from repositories, I build it myself and it always worked (not perfectly but that's another thing) until now.

I've chrooted into a FreeBSD/i386 to install a full FreeBSD with every necessary packages and I built Wine from there. It built.

...

NOTE : $CHROOT/usr/local/lib and NOT $CHROOT/usr/local/lib32 as the script says because it is chrooted, the 32-bits libs are in "lib", there isn't any lib32 folder.

Please note, building Wine from the i386 chroot without the ports system is about as much effort as building it through the i386-wine-devel port. However, the latter method is much more convenient and would help with at least some of your self-inflicted issues (for example, the one in this thread).
 
That must be related.
For the patch-nvidia thing, I just never use it normally. I tried this time BECAUSE I have the problem (it costs nothing to try). Usually, I install the nvidia-driver package from repositories.

I deleted that old libGL.so.1 and let the libGL.so.1 linked to the libGL-NVIDIA.so.1 from that nvidia-driver-390.77 package. The problem is still there.

EDIT : I forgot to say that I tried with the NVIDIA-FreeBSD-x86-390.77.tar.gz file and the result is exactly the same :)
 
Don't worry for my efforts, I'm fine building it through a chroot. I've already scripted it all out.

That i386-wine-devel package is working fine on big games but isn't as good as the one I do through chroot for less ressourceful games. So yes, I use both already. Don't ask me why, that's what I'm trying to figure out since months, I even posted here but never got any answer.
 
Don't worry for my efforts, I'm fine building it through a chroot. I've already scripted it all out.

Well, consider the amount of effort forum members would have to spend answering your question (vs i386-wine-devel package). It might be a typical problem, but first we need to assess the state of your system (i386 chroot in this case): which packages you actually have installed, what files you have copied by hand, configuration, patches, etc. This could easily take several posts and multiple hours. The only reason non-package questions are even allowed there is that *BSD users are generally expected to be able to do basic troubleshooting themselves and should not need that much handholding.

That i386-wine-devel package is working fine on big games but isn't as good as the one I do through chroot for less ressourceful games. So yes, I use both already. Don't ask me why, that's what I'm trying to figure out since months, I even posted here but never got any answer.

What?
 
Well, consider the amount of effort forum members would have to spend answering your question (vs i386-wine-devel package). It might be a typical problem, but first we need to assess the state of your system (i386 chroot in this case): which packages you actually have installed, what files you have copied by hand, configuration, patches, etc. This could easily take several posts and multiple hours spent. The only reason non-package questions are even allowed there is that *BSD users are generally expected to be able to do basic troubleshooting themselves and should not need that much handholding.

I installed FreeBSD/amd64 11.2
Here is the list of my packages :
autoconf
automake
bash
bison
cmake
dmenu
dosbox
feh
finch
firefox
gettext
git
gmake
gnome-keyring-sharp
i3
irssi
libepoll-shim
libGLU
libtool
links
moc
mpg123
mpv
mumble
ncurses
nvidia-driver
openal-soft
openvpn
p7zip
pidgin
pkgconf
portaudio
prelink
qt5
rsync
rxvt-unicode
samba46
scrot
sdl2
sdl2_image
sdl2_net
sdl2_ttf
soundtouch
terminus-font
transmission-gtk
unrar
vim
vimb-gtk3
wx30-gtk2
xorg

I also use this list to install my packages in the i386 chroot. I know I don't need all of it but it's just really quick when it's scripted, I don't have to care about the installation. So, it means my amd64 and my i386 both have all the same packages.

What I do next ?

I download the latest sources of wine, I apply 2 patches directly from /usr/ports/emulators/wine-devel/files :

patch-libinotify
patch-dlls_iphlpapi_ipstats.c

Without them, Wine won't build.

After that, I cd to /usr/local/lib of my chroot and I delete the libGL.so.1 symlink to create a new one with this commande : ln -s libGL-NVIDIA.so.1 libGL.so.1

After that, to use Wine, I wrote an executable file I put in my $PATH : LD_32_LIBRARY_PATH=/home/Adrien2002/Programmes/FreeBSD32/usr/local/lib /home/Adrien2002/Programmes/FreeBSD32/usr/local/bin/wine "$@"

Now, when I write "wine" in my terminal, it calls Wine and do the job. That's absolutely ALL I did. Really.


I have used that i386-wine-devel for years as the only Wine of FreeBSD but it has some troubles and those troubles, I don't meet them with my Wine.
What I have noticed is that, with the i386-wine-devel, you can't set the prefix to Windows 7 or higher without suffering of a stuttering sound (something I don't have with my Wine built in the chroot) but in the other hand, i386-wine-devel can handle big games with less troubles than my Wine. i386-wine-devel can run Skyrim almost perfectly but my Wine isn't. Also, my Wine can play games like Oblivion with music when i386-wine-devel can't (no music in the game with i386-wine-devel).
i386-wine-devel isn't perfect, mine either, so I build my Wine + I install the i386-wine-devel package to have the highest compatibility possible to play on FreeBSD. Both have troubles and I try my best to communicate them to Wine to help FreeBSD to become a better OS for video games so, please, don't insult me saying I need THAT MUCH handholding man. Please. I always troubleshoot and fix things by myself but when after an update, nothing works anymore... Well I've spent hours already blaming myself for something I must have forgotten. I really tried to fix this issue and I know that if I return to an older version, things will work again as it should but before to do that, I try to understand what's wrong and why. I know I'm not an expert in BSD stuff and, only sometimes, I try the human contact to solve my problems instead of manuals.

I have the exact same error message trying to run a game when using i386-wine-devel so you can even totally forget I have a chrooted environment and only focus on i386-wine-devel if you prefer.
 
Does LD_32_LIBRARY_PATH=/usr/local/lib32:/home/Adrien2002/Programmes/FreeBSD32/usr/local/lib /home/Adrien2002/Programmes/FreeBSD32/usr/local/bin/wine "$@" make a difference?

What I have noticed is that, with the i386-wine-devel, you can't set the prefix to Windows 7 or higher without suffering of a stuttering sound (something I don't have with my Wine built in the chroot)

Must be something specific to your configuration.
 
Does LD_32_LIBRARY_PATH=/usr/local/lib32:/home/Adrien2002/Programmes/FreeBSD32/usr/local/lib /home/Adrien2002/Programmes/FreeBSD32/usr/local/bin/wine "$@" make a difference?

Unfortunately no. The error message is still exactly the same as in my first message.

Must be something specific to your configuration.

That's mostly the problem, I just can't figure out EXACTLY what is done through the build of i386-wine-devel. The Makefile still impress me. It does something different than my build cause the two Wine I have in my computer act so differently... I wish I had more knowledges about ports (but this is another problem I really wish to understand ans solve one day because I love FreeBSD).
 
Let's try truss /home/Adrien2002/Programmes/FreeBSD32/usr/local/bin/glxgears (you need to install mesa-demos). Maybe there are some pointers there.
 
LATE EDIT : Wow, sorry, I didn't read entirely the command... Ok so here is what I have when I do exactly your command :

$ truss /home/Adrien2002/Programmes/FreeBSD32/usr/local/bin/glxgears
freebsd32_mmap(0x0,0x8000,0x3,0x1002,0xffffffff,0x0,0x0) = 671518720 (0x28069000)
issetugid() = 0 (0x0)
freebsd32_lstat(0x2806e000,0xffffc408) = 0 (0x0)
freebsd32_lstat(0x2806e000,0xffffc408) ERR#2 'No such file or directory'
openat(AT_FDCWD,"/var/run/ld-elf32.so.hints",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\v\0\0\0"...,128) = 128 (0x80)
freebsd32_fstat(0x3,0xffffca00) = 0 (0x0)
freebsd32_lseek(0x3,0x80,0x0,0x0) = 128 (0x80)
read(3,"/usr/lib32\0",11) = 11 (0xb)
close(3) = 0 (0x0)
access("/usr/lib32/libGLEW.so.2",F_OK) ERR#2 'No such file or directory'
access("/lib32/libGLEW.so.2",F_OK) ERR#2 'No such file or directory'
access("/usr/lib32/libGLEW.so.2",F_OK) ERR#2 'No such file or directory'
Shared object "libGLEW.so.2" not found, required by "glxgears"write(2,"Shared object "libGLEW.so.2" not"...,62) = 62 (0x3e)

write(2,"\n",1) = 1 (0x1)
exit(0x1)
process exit, rval = 1

Sure, it doesn't find the lib32 libraries so... Let's try now with the LD_32_LIBRARY_PATH var : https://pastebin.com/pJiB31nE (it's a bit long so I "pastebin"ed it).

/LATE EDIT

Good idea ! The result is exactly the SAME as with Wine


$ LD_32_LIBRARY_PATH=/usr/local/lib32:/home/Adrien2002/Programmes/FreeBSD32/usr/local/lib /home/Adrien2002/Programmes/FreeBSD32/usr/local/bin/glxgears
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 28
Current serial number in output stream: 29


EDIT : glxgears works with FreeBSD/amd64. It seems the problem is only related to the 32-bits acceleration
 
I tried to launch anything requiring 3D acceleration in 32-bits and dmesg said me that :

Aug 7 06:33:17 FreeBSD-Portable kernel: NVRM: API mismatch: the client has the version 390.67, but
Aug 7 06:33:17 FreeBSD-Portable kernel: NVRM: this kernel module has the version 390.77. Please
Aug 7 06:33:17 FreeBSD-Portable kernel: NVRM: make sure that this kernel module and all NVIDIA driver
Aug 7 06:33:17 FreeBSD-Portable kernel: NVRM: components have the same version.

Where can be that 390.67 ?? In my chroot ? Can it be the cause of the problem ?
 
Oh God... I feel so shame :( that was indeed the problem. Let me explain you why.

Usually, as a stable user, nvidia-driver's modules are compatible with FreeBSD out-of-the-box but this time I had to build the driver by myself and I didn't realize AT ALL the version was more recent in ports than in pkg...

And, the second thing is that, because I don't need to load the module for the chroot, I just install nvidia-driver from the pkg.

Different version causes all that shit. So I simply built it in my chroot and now, nvidia-driver 32 & 64-bits are both to the same version and I see all my games running again ! Just like before !!

You, dear shkhln, you are damn good :) thank you very very much for your patience (with me, it's really complicated, I admit it).
 
Honestly, I'm having trouble remembering Nvidia's minor release numbers, so I didn't notice the mismatch at all. Anyway, make sure to always look at the appropriate logs before starting to debug something and you'll be fine.
 
Back
Top