Gentoo Archives: gentoo-dev

From: Lars Pechan <lars.pechan@××××××××××××.nz>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] libGLcore error
Date: Wed, 05 Jun 2002 16:00:13
Message-Id: 200206060900.08741.lars.pechan@paradise.net.nz
In Reply to: Re: [gentoo-dev] libGLcore error by Martin Schlemmer
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

Replies

Subject Author
Re: [gentoo-dev] libGLcore error Martin Schlemmer <azarah@g.o>