1 |
Please see comments below... |
2 |
On Tue, 04 Jun 2002 15:47, Prashanth Aditya Susarla wrote: |
3 |
> > Two phased workaround: |
4 |
> > |
5 |
> > At linktime, i.e when building/doing emerges: |
6 |
> > Make sure xfree's opengl implementation is active, i.e. that the libGL.so |
7 |
> > symlink points to xfree's libGL.so, not nvidia's. |
8 |
> > |
9 |
> > opengl-update xfree |
10 |
> > emerge pkg |
11 |
> > opengl-update nvidia |
12 |
> > |
13 |
> > (using LDFLAGS=-lgcc_s emerge pkg should also work). |
14 |
> |
15 |
> If you look at the nvidia-glx package, it contains precompiled libraries |
16 |
> which you just install to their respective locations. So this part doesn't |
17 |
> make any difference. |
18 |
|
19 |
It is precisely because it is a precompiled library that it does make a |
20 |
difference. To point out what perhaps is obvious: had it been source we'd |
21 |
never had the problem in the first place. |
22 |
|
23 |
Nvidia's libGL.so.1 implicitly references a symbol in another library without |
24 |
explicitly stating that as a dependency (ldd libGL.so should list libgcc_s |
25 |
but doesn't). When compiling apps linked against nvidia's libGL this causes a |
26 |
link failure. (To complicate things further it _may be_ that only certain |
27 |
types of libGL operations cause the problem to emerge, I'm not sure) |
28 |
|
29 |
/usr/lib/libGL.so is a link that points to either the nvidia or the xfree |
30 |
implementation. By making sure that libGL from xfree is current and thus used |
31 |
during the link phase the link error won't happen and whatever you're |
32 |
building will build. The xfree version has been built from source on your |
33 |
very machine and doesn't have this problem so that sorts build-time but not |
34 |
runtime. Hence, you also need the runtime "fix". |
35 |
|
36 |
> > At runtime: |
37 |
> > Either add /lib/libgcc_s.so.1 to /etc/ld.so.preload or use LD_PRELOAD on |
38 |
> > libgcc_s. If you go for the ld.so.preload option you need to make sure |
39 |
> > you re-enter the line of text after doing an rsync as rsync overwrites it |
40 |
> |
41 |
> I did this using /etc/ld.so.preload and ran glxgears after switching to |
42 |
> the nvidia interface. glxgears segfaulted. It was runnng fine otherwise. |
43 |
> mplayer *seems* to be working fine. (I don't have a video file immediately |
44 |
> at hand). I also use another library which I load with LD_PRELOAD. I hope |
45 |
> that the two don't *clash* or something. Is it possible to preload multiple |
46 |
> libraries? And if so, how. |
47 |
> |
48 |
You need to restart X after making the change to ld.so.preload. After having |
49 |
restarted verify that either glxgears or the nvidia lib lists libgc_s when |
50 |
ldd'ed. That is, you should see something like this: |
51 |
|
52 |
basil smpeg-xmms-0.3.4 # ldd /usr/lib/libGL.so.1 |
53 |
/lib/libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40049000) |
54 |
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x4005e000) |
55 |
libm.so.6 => /lib/libm.so.6 (0x403ec000) |
56 |
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4040f000) |
57 |
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4041f000) |
58 |
libdl.so.2 => /lib/libdl.so.2 (0x404ea000) |
59 |
libc.so.6 => /lib/libc.so.6 (0x404ed000) |
60 |
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) |
61 |
|
62 |
|
63 |
I'm not overly familiar with mplayer but is it possible that opengl is only |
64 |
used for certain media types and that you'll get away without it most of the |
65 |
time? |
66 |
|
67 |
LD_PRELOADing should be fine as long as you're not preloading libraries |
68 |
containing the same symbols, I think. LD_PRELOAD="-lgcc_s -lpthread" should |
69 |
do it. |
70 |
|
71 |
I hope this does help, as I've been using this setup for a (little) while now |
72 |
without any dramas at all. Please let me know if you can't get it working and |
73 |
I'll see if I can help. |
74 |
|
75 |
Regards, |
76 |
|
77 |
/Lasse |