*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@xxxxxxxxxxx>
> Cornell University
>
--
Shahms E. King <shahms@xxxxxxxxxx>
Multnomah ESD
Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B
Attachment:
signature.asc
Description: This is a digitally signed message part
