1 |
Thanks a lot but I would like to think that I have put quite a big effort into |
2 |
finding out a) why nvidia's opengl driver doesn't work and b) how to get it |
3 |
working. So have others too. I also think I have a reasonable understading of |
4 |
what is going on. |
5 |
|
6 |
For more info on the subject see these threads in the forums: |
7 |
|
8 |
http://forums.gentoo.org/viewtopic.php?t=3701 |
9 |
http://forums.gentoo.org/viewtopic.php?t=3963 |
10 |
|
11 |
Also the following url helps in mapping out what the issues are |
12 |
http://sources.redhat.com/ml/libc-alpha/2002-04/msg00025.html. |
13 |
|
14 |
Also, the link you are referring to is mentioned in the forum postings. |
15 |
|
16 |
In short, yes the problem stems from the gcc-team having changed the layout of |
17 |
a library by hiding certain symbols. However, it's not clear whether this |
18 |
happened for 3.1 or in fact earlier. It did work earlier because the |
19 |
linker/binutils didn't care about the .hidden attribute anyway and in fact |
20 |
still works under 3.1 depending on what version of binutils is used. |
21 |
|
22 |
To see this happening try building one system with binutils 2.12 and one with |
23 |
2.11 _both_ using gcc-3.1. The nvidia opengl driver will work on one but not |
24 |
the other despite both having been compiled with the same compiler. That |
25 |
doesn't make it binutils' "fault" but it is clear that what version of |
26 |
binutils you use produce different end results. |
27 |
|
28 |
My concern hasn't been to find someone to put the blame on but to understand |
29 |
what is happening and how to fix it. I personally think one has to be very |
30 |
careful playing the blame game in an open source environment. |
31 |
|
32 |
I'm not suggesting it's nvidias "fault", if anything I'm grateful for them |
33 |
providing good drivers even if they are binaries. However, I am suggesting |
34 |
that nvidia have been caught unawares by the change and also that their |
35 |
library wouldn't build on my (or any other gcc-3.1 + latest binutils) system. |
36 |
|
37 |
I'm also suggesting a couple of workarounds for those who can't get opengl |
38 |
going on their new shiny 3.1-built systems. Some have (I believe) been |
39 |
successful in applying the patch to glibc but others haven't and for them |
40 |
these workarounds will do the trick. |
41 |
|
42 |
/Lasse |
43 |
|
44 |
On Thu, 06 Jun 2002 08:10, Martin Schlemmer wrote: |
45 |
> On Wed, 2002-06-05 at 06:26, Lars Pechan wrote: |
46 |
> > Please see comments below... |
47 |
> > |
48 |
> > On Tue, 04 Jun 2002 15:47, Prashanth Aditya Susarla wrote: |
49 |
> > > > Two phased workaround: |
50 |
> > > > |
51 |
> > > > At linktime, i.e when building/doing emerges: |
52 |
> > > > Make sure xfree's opengl implementation is active, i.e. that the |
53 |
> > > > libGL.so symlink points to xfree's libGL.so, not nvidia's. |
54 |
> > > > |
55 |
> > > > opengl-update xfree |
56 |
> > > > emerge pkg |
57 |
> > > > opengl-update nvidia |
58 |
> > > > |
59 |
> > > > (using LDFLAGS=-lgcc_s emerge pkg should also work). |
60 |
> > > |
61 |
> > > If you look at the nvidia-glx package, it contains precompiled |
62 |
> > > libraries which you just install to their respective locations. So this |
63 |
> > > part doesn't make any difference. |
64 |
> > |
65 |
> > It is precisely because it is a precompiled library that it does make a |
66 |
> > difference. To point out what perhaps is obvious: had it been source we'd |
67 |
> > never had the problem in the first place. |
68 |
> > |
69 |
> > Nvidia's libGL.so.1 implicitly references a symbol in another library |
70 |
> > without explicitly stating that as a dependency (ldd libGL.so should list |
71 |
> > libgcc_s but doesn't). When compiling apps linked against nvidia's libGL |
72 |
> > this causes a link failure. (To complicate things further it _may be_ |
73 |
> > that only certain types of libGL operations cause the problem to emerge, |
74 |
> > I'm not sure) |
75 |
> > |
76 |
> > /usr/lib/libGL.so is a link that points to either the nvidia or the xfree |
77 |
> > implementation. By making sure that libGL from xfree is current and thus |
78 |
> > used during the link phase the link error won't happen and whatever |
79 |
> > you're building will build. The xfree version has been built from source |
80 |
> > on your very machine and doesn't have this problem so that sorts |
81 |
> > build-time but not runtime. Hence, you also need the runtime "fix". |
82 |
> |
83 |
> I think you guys should do a bit more research before |
84 |
> making conclusions. There is nothing wrong with nvidia's |
85 |
> libraries, except that the gcc team changed things (like |
86 |
> usual) without letting people know, or putting a fix out |
87 |
> there. |
88 |
> |
89 |
> From the mail of the guy who patched it: |
90 |
> |
91 |
> -----------------------snip-------------------------------- |
92 |
> gcc 3.1 libgcc.a has all its routines .hidden, so they cannot |
93 |
> be re-exported from glibc that way. The following patch adds |
94 |
> the code to glibc (btw: it is smaller than what libgcc.a has, |
95 |
> since I replaced __negdi2 with normal negation, so there is |
96 |
> no need to run the values through memory too many times, plus |
97 |
> there is just one __udivmoddi4 while libgcc2.c sucks it in 4 |
98 |
> times). |
99 |
> -----------------------snip-------------------------------- |
100 |
> |
101 |
> Meaning it is only a gcc-3.1 problem. Another reason |
102 |
> why I think the gcc team went mad after 2.95.* :/ |
103 |
> |
104 |
> > > > At runtime: |
105 |
> > > > Either add /lib/libgcc_s.so.1 to /etc/ld.so.preload or use LD_PRELOAD |
106 |
> > > > on libgcc_s. If you go for the ld.so.preload option you need to make |
107 |
> > > > sure you re-enter the line of text after doing an rsync as rsync |
108 |
> > > > overwrites it |
109 |
> > > |
110 |
> > > I did this using /etc/ld.so.preload and ran glxgears after switching to |
111 |
> > > the nvidia interface. glxgears segfaulted. It was runnng fine |
112 |
> > > otherwise. mplayer *seems* to be working fine. (I don't have a video |
113 |
> > > file immediately at hand). I also use another library which I load with |
114 |
> > > LD_PRELOAD. I hope that the two don't *clash* or something. Is it |
115 |
> > > possible to preload multiple libraries? And if so, how. |
116 |
> > |
117 |
> > You need to restart X after making the change to ld.so.preload. After |
118 |
> > having restarted verify that either glxgears or the nvidia lib lists |
119 |
> > libgc_s when ldd'ed. That is, you should see something like this: |
120 |
> > |
121 |
> > basil smpeg-xmms-0.3.4 # ldd /usr/lib/libGL.so.1 |
122 |
> > /lib/libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40049000) |
123 |
> > libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x4005e000) |
124 |
> > libm.so.6 => /lib/libm.so.6 (0x403ec000) |
125 |
> > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4040f000) |
126 |
> > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4041f000) |
127 |
> > libdl.so.2 => /lib/libdl.so.2 (0x404ea000) |
128 |
> > libc.so.6 => /lib/libc.so.6 (0x404ed000) |
129 |
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) |
130 |
> > |
131 |
> > |
132 |
> > I'm not overly familiar with mplayer but is it possible that opengl is |
133 |
> > only used for certain media types and that you'll get away without it |
134 |
> > most of the time? |
135 |
> > |
136 |
> > LD_PRELOADing should be fine as long as you're not preloading libraries |
137 |
> > containing the same symbols, I think. LD_PRELOAD="-lgcc_s -lpthread" |
138 |
> > should do it. |
139 |
> > |
140 |
> > I hope this does help, as I've been using this setup for a (little) while |
141 |
> > now without any dramas at all. Please let me know if you can't get it |
142 |
> > working and I'll see if I can help. |
143 |
> > |
144 |
> > Regards, |
145 |
> > |
146 |
> > /Lasse |
147 |
> > _______________________________________________ |
148 |
> > gentoo-dev mailing list |
149 |
> > gentoo-dev@g.o |
150 |
> > http://lists.gentoo.org/mailman/listinfo/gentoo-dev |