[SOLVED] libGL error: unable to load driver: swrast_dri.so

[Zucca]

So. As the topic says.

I'm also out of ideas here. :(
Anyway. I lost OpenGL. Actually the whole dri cabability, i think. I cannot play videos unless I'm specifying x11 as video output driver. Firefox makes random crashes also.
This is propably the only error message I can get from anywhere:

Code: Select all

name of display: :0
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
libGL: dlopen /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: undefined symbol: _ZN4llvm19RTDyldMemoryManager25getSymbolAddressInProcessERKSs)
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:  153 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  48
  Current serial number in output stream:  47

At first there was some libgl.so (I think) also as a problem lib. But that went away when I rebuilt several graphics related libraries.
Now every program trying to access that swrast_dri.so will crash. Usually segfault.

I believe that there's a simple answer to this, but my ddg-fu didn't yield to anything.

EDIT01: Now investigating the problem via ssh (using segfaulting programs was a PITA).
The library in question seems to belong to mesa:

Code: Select all

 * Searching for /usr/lib64/mesa/kms_swrast_dri.so,/usr/lib64/mesa/swrastg_dri.so,/usr/lib64/mesa/swrast_dri.so,/usr/lib64/gallium-pipe/pipe_swrast.so ... 
media-libs/mesa-12.0.1 (/usr/lib64/mesa/swrastg_dri.so)
media-libs/mesa-12.0.1 (/usr/lib64/gallium-pipe/pipe_swrast.so)
media-libs/mesa-12.0.1 (/usr/lib64/mesa/kms_swrast_dri.so)
media-libs/mesa-12.0.1 (/usr/lib64/mesa/swrast_dri.so)

... I'll try some magic unless some of you knows better. :P

EDIT02: Ha! I found this:

gcc-5 uses a new C++ ABI. If you want to use LLVM libraries with gcc-5
you must build LLVM with gcc-5, too. Building LLVM with gcc-4.9 and
then using gcc-5 to build e.g. mesa will fail.

... Aaaaaand that's most propably the reason why things don't work as planned. I've been using gcc5 to build few packages, llvm and clang being one of them. I originally put few packages to be built with gcc5 because gcc4 compiled versions of them just caused segfaults.
I'll go trough my settings and set all "central" packages to be built with gcc4 until I switch fully to gcc5. I'll make a final (hopefully) report If this gets solved.
In meantime... Is it possible to set the old C++ ABI when using gcc5 so that packages could be compatible with each other?

[Zucca]

And after compiling few packages with gcc4 I have dri working again.
Need to be more careful with compiling central stuff with different versions of compilers. Actually it's best to use the same version only, unless some package needs a different version compiler.

[Petross404]

I just managed to solve a libGL.so error :

Code: Select all

strace -o gl.strace dolphin
cat gl.strace | grep GL

open("/usr/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = 3
....

Code: Select all

sudo fquery b /usr/lib64/libGL.so.1

fquery informed me that libGL.so links to /usr/lib64/libGL.so.1.2.0 that belongs to mesa. So the solution was to fix the symlink:

Code: Select all

sudo ln -fs /usr/lib64/opengl/nvidia/lib/libGL.so.1.0.0 /usr/lib64/libGL.so.1

I suspect the problem begun when I