1 |
Since we updated to the new NVIDIA drivers layout I have seen a lot of |
2 |
noise about it in -users and in the bug tracker. I still think that |
3 |
we did the right thing by moving the drivers into /opt, and I still |
4 |
think that the applications that don't honor run-time linker's |
5 |
resolution of libGL.so to /opt/nvidia/lib are broken. However, I |
6 |
think that we can improve the situation a bit. |
7 |
|
8 |
Some premises: |
9 |
1. Drobbins voice a hypothesis that some programs (quake) have |
10 |
"/usr/lib/libGL.so" hardcoded and use a system call to load the |
11 |
lbrary. |
12 |
2. It seems that compilation sybsystems of other programs (gltron, |
13 |
perhaps?) define run-time library paths at compile time by passing the |
14 |
linker "-rpath" option. |
15 |
3. Xfree installs *symlinks* |
16 |
/usr/lib/libGL.so -> /usr/X11R6/lib/libGL.so |
17 |
/usr/lib/libGL.so.1 -> /usr/X11R6/lib/libGL.so.1 |
18 |
it's important that they are symlinks. |
19 |
|
20 |
A possible solution: |
21 |
1. Xfree ebuild does *not* install the symlinks. |
22 |
2. Instead we create a separate package that would install just the |
23 |
symlinks into /usr/lib (for people that do not use NVIDIA drivers). |
24 |
We can name it "xfree-gl-symlinks" or just "xfree-gl". |
25 |
3. For the people who use NVIDIA drivers, we make nvidia-glx pacakge |
26 |
install the synlinks in /usr/lib, pointing to /opt/nvidia/lib, |
27 |
naturally. |
28 |
|
29 |
This ain't pretty, and it's a kludge. I don't like it much, but I |
30 |
think that this will make lives of many users easier, at a nominal |
31 |
cost. If anyone can think of another way to fix the problem, I hope |
32 |
that a better idea exits. ;^) |
33 |
|
34 |
Comments? |
35 |
-- |
36 |
Arcady Genkin |
37 |
Don't read everything you believe. |