Comment # 6 on bug 1017360 from Stefan Dirsch

(In reply to Robert Nelson from comment #4)
> Bingo! You are right, they must not be referencing /etc/ld.so.conf.d in
> their dlopen() calls (which I agree is an application bug).
> 
> When I run the following script, all is well:
> 
> for i in libEGL_nvidia.so.0 libEGL.so.1 libGLdispatch.so.0 \
> libGLESv1_CM_nvidia.so.1 libGLESv1_CM.so.1 libGLESv2_nvidia.so.2
> libGLESv2.so.2 \
> libGL.la libGL.so libGL.so.1 libGLX_nvidia.so.0 libOpenGL.so.0
>         do
>         rm -f /usr/lib64/${i}
>         ln -s /usr/X11R6/lib64/${i} /usr/lib64
> done
> 
> I did it this way instead of copying or linking everything, since with just
> these links, things will continue to work when a new version of the Nvidia
> driver comes out. However, updates to any of these /usr/lib64 files from
> other repositories (e.g., the one with the nouveau drivers) could replace my
> links, making things break again until the script is rerun. Still, this is
> better than having to go to nvidia.com and download and run their driver
> script with every update.
> 
> The nvidia.com install apparently installs everything in /usr/lib and
> /usr/lib64, so this problem doesn't come up. Is there a reason the community
> repository doesn't do it this way? Perhaps you were trying to avoid the
> problem with updates from other repositories.

Exactly, the next Mesa update would break things again. We don't want to mess
up the system as it's done with NVIDIA's installer. BTW, NVIDIA's installer
makes backups of the Mesa libs and reinstalls these during uninstall.