PDA

View Full Version : Wine installation broke library linking



nvparrish
20th November 2017, 11:20 PM
I installed wine on my Fedora 25 system. The program I was trying to run, however, was 32-bit. I made sure that I installed all the appropriate 32-bit mesa drivers. The program still wouldn't run. I then tried using another program and it failed to work. I ended up doing a system restart.

When the system came back up, Xorg wouldn't work (though Wayland was still fine.) I also couldn't run several of my programs. The common thread seemed to be OpenGL. Reading some forums, I found the suggestion to set LIBG_DEBUG to verbose and run glxinfo.


$export LIBGL_DEBUG=verbose


$glxinfo
name of display: :0
libGL: Can't open configuration file /home/nvparrish-f/.drirc: No such file or directory.
libGL: pci id for fd 6: 8086:0412, driver i965
libGL: OpenDriver: trying /usr/lib/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/dri/i965_dri.so
libGL: dlopen /usr/lib/dri/i965_dri.so failed (/usr/lib/dri/i965_dri.so: wrong ELF class: ELFCLASS32)
libGL error: unable to load driver: i965_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i965
libGL: pci id for fd 6: 8086:0412, driver i965
libGL: OpenDriver: trying /usr/lib/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/dri/i965_dri.so
libGL: dlopen /usr/lib/dri/i965_dri.so failed (/usr/lib/dri/i965_dri.so: wrong ELF class: ELFCLASS32)
libGL error: unable to load driver: i965_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i965
libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
libGL: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: wrong ELF class: ELFCLASS32)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request: GLXBadContext
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 57
Current serial number in output stream: 56




$ldd /bin/glxinfo
linux-vdso.so.1 (0x00007ffdf9596000)
libGL.so.1 => /lib/libGL.so.1 (0x00007f4bcc9ed000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f4bcc6af000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4bcc2ca000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f4bcc098000)
libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0 (0x00007f4bcbe95000)
libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x00007f4bcbc8d000)
libxcb-present.so.0 => /lib64/libxcb-present.so.0 (0x00007f4bcba8a000)
libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007f4bcb883000)
libxshmfence.so.1 => /lib64/libxshmfence.so.1 (0x00007f4bcb680000)
libglapi.so.0 => /lib64/libglapi.so.0 (0x00007f4bcb450000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007f4bcb23e000)
libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f4bcb03b000)
libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f4bcae35000)
libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f4bcac33000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f4bcaa0b000)
libxcb-glx.so.0 => /lib64/libxcb-glx.so.0 (0x00007f4bca7f0000)
libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x00007f4bca5eb000)
libXxf86vm.so.1 => /lib64/libXxf86vm.so.1 (0x00007f4bca3e5000)
libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f4bca1d4000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4bc9e7f000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4bc9c60000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4bc9a5c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4bcce64000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007f4bc9858000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f4bc962f000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f4bc93ab000)


It seems that it is now trying to use the 32-bit driver. I tried removing the 32-bit mesa drivers, but that only caused it to fail to find the .so file. I found a temporary workaround by manually setting the LD_LIBRARY_PATH.



$export LD_LIBRARY_PATH=/lib64:/usr/lib64/dri


This allows the broken programs to be run from that terminal. I put that setting in /etc/environment so now when the system starts up, it allows Fedora to run my programs. Unfortunately, if the computer goes into power saving mode, I get stuck in a loop where it keeps prompting me to login and fails. I can lock my screen and come back before the power saving mode activates and it continues to work. I also can't get wine to run the 32-bit Windows program.

For comparison, after setting the LD_LIBRARY_PATH, this is the new response from ldd.



$ldd /bin/glxinfo
linux-vdso.so.1 (0x00007ffd7acc6000)
libGL.so.1 => /lib64/libGL.so.1 (0x00007fec4b3bf000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007fec4b081000)
libc.so.6 => /lib64/libc.so.6 (0x00007fec4ac9c000)
libGLX.so.0 => /lib64/libGLX.so.0 (0x00007fec4aa6a000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007fec4a858000)
libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007fec4a5a2000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fec4a39e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fec4a17f000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fec49f57000)
/lib64/ld-linux-x86-64.so.2 (0x00007fec4b858000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007fec49d53000)



Does anyone know how I broke the library linker? And more than that, how can I fix it? Bonus points if the solution fixes wine also.

nvparrish
20th December 2017, 12:56 AM
Some additional information, when using Wayland, the system is relatively stable. When using Xorg, it will crash fairly consistently after it goes into power saving mode. When I try to log in, the screen will freeze and go back to the login screen. On the second attempt, it will report that GNOME Shell quit unexpectedly. The crash function is dump_gjs_stack_on_signal_handler.