Fedora 19 using rpmfussion's NVIDIA driver: libGL error: failed to load driver: swrast - opengl

Question

When running an app that uses Qt 4.7 on my Fedora 19 box I am getting the following errors from the application:
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: Can't open configuration file /home/Matthew.Hoggan/.drirc: No such file or directory.
libGL error: failed to load driver: swrast ERROR: Error failed to create progam.
I do not see these errors in a stock X11 application where the context is configured using glx. I am assuming this is because Qt uses egl underneath. The same thing happens when using the EGL 3 emulator from http://malideveloper.arm.com/develop-for-mali/tools/opengl-es-3-0-emulator/ while running their cube example.
I have already verified that both xorg-x11-drv-nvidia-libs.i686 and yum install xorg-x11-drv-nvidia-libs.x86_64 rpms are installed.
My system information is:
Linux localhost.localdomain 3.11.9-200.fc19.x86_64 #1 SMP Wed Nov 20 21:22:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
And glxinfo is:
[Matthew.Hoggan#localhost QtTest]$ glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL core profile version string: 4.3.0 NVIDIA 331.38
OpenGL core profile shading language version string: 4.30 NVIDIA via Cg compiler
OpenGL version string: 4.4.0 NVIDIA 331.38
OpenGL shading language version string: 4.40 NVIDIA via Cg compiler
Any suggestions here or is more information needed?

Answer 1

We were able to get rid of the same error messages for octave-4.0.0-rc1 which also use Qt. The bug hunting history can be found here.
It turned out to be an incorrect runpath in a shared library (.so). The runpath contained /usr/lib64. Hence at runtime the /usr/lib64/libGL.so was loaded, instead of the right nvidia /usr/X11R6/lib64/libGL.so.
Workaround
Find the lib or executable which has the incorrect runpath with ldd <app or lib> and chrpath -l <app or lib>
Replace the wrong path with the correct one (without the offending /usr/lib64) using chrpath -r <correct path> <app or lib>
The following one-liner did this for liboctgui.so. Just replace "liboctgui.so" by your value.
chrpath -r $(chrpath -l liboctgui.so | cut -d '=' -f '2' | awk '{gsub(/\/usr\/lib64/, "")}; 1') liboctgui.so
Origin
The incorrect runpath was picked up at compilation time from an irrelevant
-L/usr/lib64 in libQt*.la files located in /usr/lib64.
The comment #18 explains why it is wrong.
And indeed, lib*.la files should not be packaged, according to OpenSUSE own recommendations
Avoid packaging libtool config files (.la files). If you do not
package a static library, and if you are also placing the shared
library in a standard search directory (i.e. %_lib, /usr/%_lib), they
will not be needed.
Removing lib*.la from /usr/lib64 and rebuilding fixed the problem for good.