1 |
On Wed, 2002-06-05 at 06:26, Lars Pechan wrote: |
2 |
> Please see comments below... |
3 |
> On Tue, 04 Jun 2002 15:47, Prashanth Aditya Susarla wrote: |
4 |
> > > Two phased workaround: |
5 |
> > > |
6 |
> > > At linktime, i.e when building/doing emerges: |
7 |
> > > Make sure xfree's opengl implementation is active, i.e. that the libGL.so |
8 |
> > > symlink points to xfree's libGL.so, not nvidia's. |
9 |
> > > |
10 |
> > > opengl-update xfree |
11 |
> > > emerge pkg |
12 |
> > > opengl-update nvidia |
13 |
> > > |
14 |
> > > (using LDFLAGS=-lgcc_s emerge pkg should also work). |
15 |
> > |
16 |
> > If you look at the nvidia-glx package, it contains precompiled libraries |
17 |
> > which you just install to their respective locations. So this part doesn't |
18 |
> > make any difference. |
19 |
> |
20 |
> It is precisely because it is a precompiled library that it does make a |
21 |
> difference. To point out what perhaps is obvious: had it been source we'd |
22 |
> never had the problem in the first place. |
23 |
> |
24 |
> Nvidia's libGL.so.1 implicitly references a symbol in another library without |
25 |
> explicitly stating that as a dependency (ldd libGL.so should list libgcc_s |
26 |
> but doesn't). When compiling apps linked against nvidia's libGL this causes a |
27 |
> link failure. (To complicate things further it _may be_ that only certain |
28 |
> types of libGL operations cause the problem to emerge, I'm not sure) |
29 |
> |
30 |
> /usr/lib/libGL.so is a link that points to either the nvidia or the xfree |
31 |
> implementation. By making sure that libGL from xfree is current and thus used |
32 |
> during the link phase the link error won't happen and whatever you're |
33 |
> building will build. The xfree version has been built from source on your |
34 |
> very machine and doesn't have this problem so that sorts build-time but not |
35 |
> runtime. Hence, you also need the runtime "fix". |
36 |
> |
37 |
|
38 |
I think you guys should do a bit more research before |
39 |
making conclusions. There is nothing wrong with nvidia's |
40 |
libraries, except that the gcc team changed things (like |
41 |
usual) without letting people know, or putting a fix out |
42 |
there. |
43 |
|
44 |
>From the mail of the guy who patched it: |
45 |
|
46 |
-----------------------snip-------------------------------- |
47 |
gcc 3.1 libgcc.a has all its routines .hidden, so they cannot |
48 |
be re-exported from glibc that way. The following patch adds |
49 |
the code to glibc (btw: it is smaller than what libgcc.a has, |
50 |
since I replaced __negdi2 with normal negation, so there is |
51 |
no need to run the values through memory too many times, plus |
52 |
there is just one __udivmoddi4 while libgcc2.c sucks it in 4 |
53 |
times). |
54 |
-----------------------snip-------------------------------- |
55 |
|
56 |
Meaning it is only a gcc-3.1 problem. Another reason |
57 |
why I think the gcc team went mad after 2.95.* :/ |
58 |
|
59 |
> > > At runtime: |
60 |
> > > Either add /lib/libgcc_s.so.1 to /etc/ld.so.preload or use LD_PRELOAD on |
61 |
> > > libgcc_s. If you go for the ld.so.preload option you need to make sure |
62 |
> > > you re-enter the line of text after doing an rsync as rsync overwrites it |
63 |
> > |
64 |
> > I did this using /etc/ld.so.preload and ran glxgears after switching to |
65 |
> > the nvidia interface. glxgears segfaulted. It was runnng fine otherwise. |
66 |
> > mplayer *seems* to be working fine. (I don't have a video file immediately |
67 |
> > at hand). I also use another library which I load with LD_PRELOAD. I hope |
68 |
> > that the two don't *clash* or something. Is it possible to preload multiple |
69 |
> > libraries? And if so, how. |
70 |
> > |
71 |
> You need to restart X after making the change to ld.so.preload. After having |
72 |
> restarted verify that either glxgears or the nvidia lib lists libgc_s when |
73 |
> ldd'ed. That is, you should see something like this: |
74 |
> |
75 |
> basil smpeg-xmms-0.3.4 # ldd /usr/lib/libGL.so.1 |
76 |
> /lib/libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40049000) |
77 |
> libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x4005e000) |
78 |
> libm.so.6 => /lib/libm.so.6 (0x403ec000) |
79 |
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4040f000) |
80 |
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4041f000) |
81 |
> libdl.so.2 => /lib/libdl.so.2 (0x404ea000) |
82 |
> libc.so.6 => /lib/libc.so.6 (0x404ed000) |
83 |
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) |
84 |
> |
85 |
> |
86 |
> I'm not overly familiar with mplayer but is it possible that opengl is only |
87 |
> used for certain media types and that you'll get away without it most of the |
88 |
> time? |
89 |
> |
90 |
> LD_PRELOADing should be fine as long as you're not preloading libraries |
91 |
> containing the same symbols, I think. LD_PRELOAD="-lgcc_s -lpthread" should |
92 |
> do it. |
93 |
> |
94 |
> I hope this does help, as I've been using this setup for a (little) while now |
95 |
> without any dramas at all. Please let me know if you can't get it working and |
96 |
> I'll see if I can help. |
97 |
> |
98 |
> Regards, |
99 |
> |
100 |
> /Lasse |
101 |
> _______________________________________________ |
102 |
> gentoo-dev mailing list |
103 |
> gentoo-dev@g.o |
104 |
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev |
105 |
-- |
106 |
|
107 |
Martin Schlemmer |
108 |
Gentoo Linux Developer, Desktop Team Developer |
109 |
Cape Town, South Africa |