Gentoo Archives: gentoo-dev

From: Martin Schlemmer <azarah@g.o>
To: Gentoo-Dev <gentoo-dev@g.o>
Subject: Re: [gentoo-dev] libGLcore error
Date: Wed, 05 Jun 2002 15:12:06
Message-Id: 1023307867.7489.45.camel@nosferatu.lan
In Reply to: Re: [gentoo-dev] libGLcore error by Lars Pechan
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

Replies

Subject Author
Re: [gentoo-dev] libGLcore error Lars Pechan <lars.pechan@××××××××××××.nz>