Nvidia packaging for Fedora

Shahms King shahms at shahms.com
Fri Jan 28 18:11:07 UTC 2005


*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 at cornell.edu>
> Cornell University
> 
-- 
Shahms E. King <shahms at shahms.com>
Multnomah ESD

Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA  AB1B FEAB 3636 45B2 D75B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050128/4b82eabe/attachment-0002.bin 


More information about the devel mailing list