From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <azarah@gentoo.org> X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI, NICE_REPLY_A autolearn=unavailable autolearn_force=no version=4.0.0 Received: from kknd.mweb.co.za (kknd.mweb.co.za [196.2.45.79]) by chiba.3jane.net (Postfix) with ESMTP id CF40CAC3AD for <gentoo-dev@gentoo.org>; Wed, 5 Jun 2002 15:12:06 -0500 (CDT) Received: from cpt-dial-196-30-179-123.mweb.co.za ([196.30.179.123] helo=nosferatu.lan) by kknd.mweb.co.za with esmtp (Exim 4.01) id 17Fh4Y-0005op-00 for gentoo-dev@gentoo.org; Wed, 05 Jun 2002 22:07:58 +0200 Subject: Re: [gentoo-dev] libGLcore error From: Martin Schlemmer <azarah@gentoo.org> To: Gentoo-Dev <gentoo-dev@gentoo.org> In-Reply-To: <200206051626.23294.lars.pechan@paradise.net.nz> References: <Pine.LNX.4.44.0206040910430.1842-100000@thunderbird.junta.iitk.ac.in> <200206051626.23294.lars.pechan@paradise.net.nz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 05 Jun 2002 22:10:59 +0200 Message-Id: <1023307867.7489.45.camel@nosferatu.lan> Mime-Version: 1.0 Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: <mailto:gentoo-dev-request@gentoo.org?subject=help> List-Post: <mailto:gentoo-dev@gentoo.org> List-Subscribe: <http://lists.gentoo.org/mailman/listinfo/gentoo-dev>, <mailto:gentoo-dev-request@gentoo.org?subject=subscribe> List-Id: Gentoo Linux developer list <gentoo-dev.gentoo.org> List-Unsubscribe: <http://lists.gentoo.org/mailman/listinfo/gentoo-dev>, <mailto:gentoo-dev-request@gentoo.org?subject=unsubscribe> List-Archive: <http://lists.gentoo.org/pipermail/gentoo-dev/> X-Archives-Salt: 33f7adb0-a225-4a5b-8654-2399fd517564 X-Archives-Hash: fcf38bdaf70d097a6bf70ea8caeee123 On Wed, 2002-06-05 at 06:26, Lars Pechan wrote: > Please see comments below... > On Tue, 04 Jun 2002 15:47, Prashanth Aditya Susarla wrote: > > > Two phased workaround: > > > > > > At linktime, i.e when building/doing emerges: > > > Make sure xfree's opengl implementation is active, i.e. that the libGL.so > > > symlink points to xfree's libGL.so, not nvidia's. > > > > > > opengl-update xfree > > > emerge pkg > > > opengl-update nvidia > > > > > > (using LDFLAGS=-lgcc_s emerge pkg should also work). > > > > If you look at the nvidia-glx package, it contains precompiled libraries > > which you just install to their respective locations. So this part doesn't > > make any difference. > > It is precisely because it is a precompiled library that it does make a > difference. To point out what perhaps is obvious: had it been source we'd > never had the problem in the first place. > > Nvidia's libGL.so.1 implicitly references a symbol in another library without > explicitly stating that as a dependency (ldd libGL.so should list libgcc_s > but doesn't). When compiling apps linked against nvidia's libGL this causes a > link failure. (To complicate things further it _may be_ that only certain > types of libGL operations cause the problem to emerge, I'm not sure) > > /usr/lib/libGL.so is a link that points to either the nvidia or the xfree > implementation. By making sure that libGL from xfree is current and thus used > during the link phase the link error won't happen and whatever you're > building will build. The xfree version has been built from source on your > very machine and doesn't have this problem so that sorts build-time but not > runtime. Hence, you also need the runtime "fix". > I think you guys should do a bit more research before making conclusions. There is nothing wrong with nvidia's libraries, except that the gcc team changed things (like usual) without letting people know, or putting a fix out there. >>From the mail of the guy who patched it: -----------------------snip-------------------------------- gcc 3.1 libgcc.a has all its routines .hidden, so they cannot be re-exported from glibc that way. The following patch adds the code to glibc (btw: it is smaller than what libgcc.a has, since I replaced __negdi2 with normal negation, so there is no need to run the values through memory too many times, plus there is just one __udivmoddi4 while libgcc2.c sucks it in 4 times). -----------------------snip-------------------------------- Meaning it is only a gcc-3.1 problem. Another reason why I think the gcc team went mad after 2.95.* :/ > > > At runtime: > > > Either add /lib/libgcc_s.so.1 to /etc/ld.so.preload or use LD_PRELOAD on > > > libgcc_s. If you go for the ld.so.preload option you need to make sure > > > you re-enter the line of text after doing an rsync as rsync overwrites it > > > > I did this using /etc/ld.so.preload and ran glxgears after switching to > > the nvidia interface. glxgears segfaulted. It was runnng fine otherwise. > > mplayer *seems* to be working fine. (I don't have a video file immediately > > at hand). I also use another library which I load with LD_PRELOAD. I hope > > that the two don't *clash* or something. Is it possible to preload multiple > > libraries? And if so, how. > > > You need to restart X after making the change to ld.so.preload. After having > restarted verify that either glxgears or the nvidia lib lists libgc_s when > ldd'ed. That is, you should see something like this: > > basil smpeg-xmms-0.3.4 # ldd /usr/lib/libGL.so.1 > /lib/libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40049000) > libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x4005e000) > libm.so.6 => /lib/libm.so.6 (0x403ec000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4040f000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4041f000) > libdl.so.2 => /lib/libdl.so.2 (0x404ea000) > libc.so.6 => /lib/libc.so.6 (0x404ed000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > > I'm not overly familiar with mplayer but is it possible that opengl is only > used for certain media types and that you'll get away without it most of the > time? > > LD_PRELOADing should be fine as long as you're not preloading libraries > containing the same symbols, I think. LD_PRELOAD="-lgcc_s -lpthread" should > do it. > > I hope this does help, as I've been using this setup for a (little) while now > without any dramas at all. Please let me know if you can't get it working and > I'll see if I can help. > > Regards, > > /Lasse > _______________________________________________ > gentoo-dev mailing list > gentoo-dev@gentoo.org > http://lists.gentoo.org/mailman/listinfo/gentoo-dev -- Martin Schlemmer Gentoo Linux Developer, Desktop Team Developer Cape Town, South Africa