*snip*
Possibly a packaging bug... but IMO, not caused by the presence of Mesa_GL. again, report it: bugzilla.livna.org
rpm -ql xorg-x11-Mesa-libGL* -p
/usr/X11R6/lib/libGL.so.1 /usr/X11R6/lib/libGL.so.1.2 /usr/lib/libGL.so.1
How is this supposed to work? /usr/lib/libGL.so.1 takes precedence over the nvidia folder with the same lib.
LD_LIBRARY_PATH is an answer. However, assuming your /etc/ld.so.conf is set up correctly, the /etc/ld.so.conf.d/nvidia-glx.conf should take precedence over /usr/lib. I have previously had problems with apps not finding the right GL library, but after correcting my ld.so.conf (and some upstream fixes) everything just works now. At the time, I just prepended "/usr/lib/nvidia" to the LD_LIBRARY_PATH and went merrily on my way. Note: adding libraries to LD_LIBRARY_PATH can be tricky as you don't want to have an "empty" entry, or ld looks in the current directory which is/can be insecure. Below is a bash function for correctly appending and prepending elements to an environment variable:
(Note: it might be nice to see something similar shipped with Fedora as these are pretty common operations -- PATH, etc. -- that are strangely difficult to do correctly.)
append() { local VARNAME=${1:?"Variable Not Specified"} local EXTRA=${2:?"What to prepend not specified"} local SEP=${3:-":"}
local newvar="" local oifs="$IFS" local var=$(eval "echo $${VARNAME}") IFS="$SEP" local part for part in $var; do if [ "$part" != "$EXTRA" ]; then newvar="${newvar:+${newvar}${SEP}}${part}" fi done IFS="$oifs"
eval "$VARNAME='${newvar}${SEP}${EXTRA}'" }
prepend() { local VARNAME=${1:?"Variable Not Specified"} local EXTRA=${2:?"What to prepend not specified"} local SEP=${3:-":"}
local newvar="$EXTRA" local oifs="$IFS" local var=$(eval "echo $${VARNAME}") IFS="$SEP" local part for part in $var; do if [ "$part" != "$EXTRA" ]; then newvar="${newvar}${SEP}${part}" fi done IFS="$oifs"
eval "$VARNAME='$newvar'" }
To put "/usr/lib/nvidia" safely at the front of LD_LIBRARY_PATH call: $ prepend LD_LIBRARY_PATH "/usr/lib/nvidia"
Neither of these functions are very efficient as they both completely rebuild the environment variable from its component parts, but the end result is that if you say:
append PATH "$HOME/bin"
regardless of the earlier state of the PATH variable, your "$HOME/bin" will be listed last and only last.
(alternatively, if you don't mind multiple identical entries in your PATH variables using:
LD_LIBRARY_PATH=/usr/lib/nvidia${LD_LIBRARY_PATH:+":$LD_LIBRARY_PATH"}
will also do the trick)
Even if it didn't, relying on which libGL.so.1 came first seems like a very fragile setup. I recall redirecting that link, and it was still broken since apparently it chose the one in X11R6. Then I redirected that one and it was restoring it on every ldconfig until I got rid of the library itself.
Hence, Mesa GL conflicts with nvidia-glx.
Btw why is /usr/lib/libGL.so.1 there at all?
I'm guessing here, but OpenGL isn't technically restricted to just X. (It might be effectively restricted to X at the moment, but given that the long-term plans for X are to implement it on top of libGL, having an X display clearly isn't required for using OpenGL...)
-- Ivan Gyurdiev ivg2@cornell.edu Cornell University