[gentoo-dev] libGLcore error

[gentoo-dev] libGLcore error

[Prashanth Aditya Susarla]

I emerged nvidia-kernel and nvidia-glx and configured everything to work 
properly (in the sense that I am working with X/KDE without any hassle as 
far as regular operation is concerned). However there's the following 
error in the XFree86 log file:-

dlopen: /usr/lib/libGLcore.so.1: undefined symbol: __divdi3

due to which mplayer etc. won't run. I even have a feeling I won't be able 
to quake now :-(. I see no reason why this should break. Does it have 
something to do with the compiler/optimization flags again? (gcc-3.1-r5, 
-march=athlon-tbird -mmmx -m3dnow -O3 -pipe -fomit-frame-pointer)

Regards,
Prashanth Aditya Susarla

Re: [gentoo-dev] libGLcore error

[Brandon Low]

Check out bug 3150 we've been fighting with this one for a while... there 
are also some forum threads about it wherein someone found a patch for 
glibc that supposedly fixes it, unfortunately I haven't been able to get 
that patch to compile for me.

--Brandon

-=-=-=-=-=-=-=-Previous Message(s)-=-=-=-=-=-=-=-
> I emerged nvidia-kernel and nvidia-glx and configured everything to work 
> properly (in the sense that I am working with X/KDE without any hassle as 
> far as regular operation is concerned). However there's the following 
> error in the XFree86 log file:-
> 
> dlopen: /usr/lib/libGLcore.so.1: undefined symbol: __divdi3
> 
> due to which mplayer etc. won't run. I even have a feeling I won't be able 
> to quake now :-(. I see no reason why this should break. Does it have 
> something to do with the compiler/optimization flags again? (gcc-3.1-r5, 
> -march=athlon-tbird -mmmx -m3dnow -O3 -pipe -fomit-frame-pointer)
> 
> Regards,
> Prashanth Aditya Susarla
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] libGLcore error

[Lars Pechan]

Very short summary:

There is a problem with nvidia opengl acceleration. AFAIK it only happens when 
using the latest binutils (2.12.x). I believe it's caused by nvidia's 
libGL.so not having been built with -lgcc_s as a linker directive. Previous 
versions of binutils would have made up for that by re-exporting the 
necessary symbols from libgcc_s but when using the latest version that no 
longer happens.

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). 

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

Not perfect by any means but gets the job done and is really quite painless.

For more in-depth info, check out the gcc3 forum.

/Lasse

On Tue, 04 Jun 2002 07:03, Prashanth Aditya Susarla wrote:
> I emerged nvidia-kernel and nvidia-glx and configured everything to work
> properly (in the sense that I am working with X/KDE without any hassle as
> far as regular operation is concerned). However there's the following
> error in the XFree86 log file:-
>
> dlopen: /usr/lib/libGLcore.so.1: undefined symbol: __divdi3
>
> due to which mplayer etc. won't run. I even have a feeling I won't be able
> to quake now :-(. I see no reason why this should break. Does it have
> something to do with the compiler/optimization flags again? (gcc-3.1-r5,
> -march=athlon-tbird -mmmx -m3dnow -O3 -pipe -fomit-frame-pointer)
>
> Regards,
> Prashanth Aditya Susarla
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] libGLcore error

[Prashanth Aditya Susarla]

> 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.

> 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.


Regards,
Prashanth Aditya Susarla

Re: [gentoo-dev] libGLcore error

[Lars Pechan]

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".

> > 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

Re: [gentoo-dev] libGLcore error

[Prashanth Aditya Susarla]

> 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. 

Ok, thanks for clearing that up. I was under the impression that one has 
to use -lgcc_s while compiling sources so that libgcc_s.so is linked 
dynamically at runtime. Obviously, if we had the sources...

> 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:

Thanks a lot again. Restarting X worked and I'm happy to see glxgears 
working again. Now all I have to do is quake :-).

> 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?

If you look at 
$ mplayer -vo help
you'll see certain video output drivers (basically whatever you've allowed 
during "configure" is enabled) which include the gl and gl2 video drivers 
too. These use libGL.so, and further, mplayer probes all of them at 
startup I think, which is why I got the __divid3 error on running mplayer 
before employing this fix.

> 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.

Yeah multiple LD_PRELOAD seems to be working for me. The other one which I 
use is a function interposer for connect() so it has nothing to do with 
libgcc_s.so I guess. Anyway, thanks a lot once again for the information.

Regards,
Prashanth Aditya Susarla

Re: [gentoo-dev] libGLcore error

[Lars Pechan]

On Tue, 04 Jun 2002 16:56, Prashanth Aditya Susarla wrote:
> > 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.
>
> Ok, thanks for clearing that up. I was under the impression that one has
> to use -lgcc_s while compiling sources so that libgcc_s.so is linked
> dynamically at runtime. Obviously, if we had the sources...
>

That is absolutely correct in the normal case -- unless you state the library 
on the link line you'll get a linker error. The tricky thing in this case is 
that it's the compiler itself that's generating the calls to functions in 
libgcc_s and not the user code directly. libgcc_s contains various 
housekeeping functions the compiler may call depending on the end-user code 
(some refer to it as a junk drawer that contains stuff that doesn't fit 
anywhere else). So as a developer you may not even know you are referencing 
stuff in that lib. 

The older binutils made up for that by re-exporting the symbols that were 
referenced in libgcc_s so you'd end up with a reference to libgcc_s 
implicitly. That does not happen anymore. I believe that if nvidia were to 
take the build environment they used to produce what we have and tries to do 
a build under the new binutils the library won't even build. 

Any linker gurus out there that could let me know if I'm talking shite?

/Lasse

Re: [gentoo-dev] libGLcore error

[Martin Schlemmer]

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

Re: [gentoo-dev] libGLcore error

[Lars Pechan]

Thanks a lot but I would like to think that I have put quite a big effort into 
finding out a) why nvidia's opengl driver doesn't work and b) how to get it 
working. So have others too. I also think I have a reasonable understading of 
what is going on. 

For more info on the subject see these threads in the forums:

http://forums.gentoo.org/viewtopic.php?t=3701
http://forums.gentoo.org/viewtopic.php?t=3963

Also the following url helps in mapping out what the issues are  
http://sources.redhat.com/ml/libc-alpha/2002-04/msg00025.html. 

Also, the link you are referring to is mentioned in the forum postings.

In short, yes the problem stems from the gcc-team having changed the layout of 
a library by hiding certain symbols. However, it's not clear whether this 
happened for 3.1 or in fact earlier. It did work earlier because the 
linker/binutils didn't care about the .hidden attribute anyway and in fact 
still works under 3.1 depending on what version of binutils is used.

To see this happening try building one system with binutils 2.12 and one with 
2.11 _both_ using gcc-3.1. The nvidia opengl driver will work on one but not 
the other despite both having been compiled with the same compiler. That 
doesn't make it binutils' "fault" but it is clear that what version of 
binutils you use produce different end results.

My concern hasn't been to find someone to put the blame on but to understand 
what is happening and how to fix it. I personally think one has to be very 
careful playing the blame game in an open source environment. 

I'm not suggesting it's nvidias "fault", if anything I'm grateful for them 
providing good drivers even if they are binaries. However, I am suggesting 
that nvidia have been caught unawares by the change and also that their 
library wouldn't build on my (or any other gcc-3.1 + latest binutils) system.

I'm also suggesting a couple of workarounds for those who can't get opengl 
going on their new shiny 3.1-built systems. Some have (I believe) been 
successful in applying the patch to glibc but others haven't and for them 
these workarounds will do the trick.

/Lasse

On Thu, 06 Jun 2002 08:10, Martin Schlemmer wrote:
> 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

Re: [gentoo-dev] libGLcore error

[Martin Schlemmer]

On Wed, 2002-06-05 at 23:00, Lars Pechan wrote:
> Thanks a lot but I would like to think that I have put quite a big effort into 
> finding out a) why nvidia's opengl driver doesn't work and b) how to get it 
> working. So have others too. I also think I have a reasonable understading of 
> what is going on. 
> 
> For more info on the subject see these threads in the forums:
> 
> http://forums.gentoo.org/viewtopic.php?t=3701
> http://forums.gentoo.org/viewtopic.php?t=3963
> 
> Also the following url helps in mapping out what the issues are  
> http://sources.redhat.com/ml/libc-alpha/2002-04/msg00025.html. 
> 
> Also, the link you are referring to is mentioned in the forum postings.
> 
> In short, yes the problem stems from the gcc-team having changed the layout of 
> a library by hiding certain symbols. However, it's not clear whether this 
> happened for 3.1 or in fact earlier. It did work earlier because the 
> linker/binutils didn't care about the .hidden attribute anyway and in fact 
> still works under 3.1 depending on what version of binutils is used.
> 
> To see this happening try building one system with binutils 2.12 and one with 
> 2.11 _both_ using gcc-3.1. The nvidia opengl driver will work on one but not 
> the other despite both having been compiled with the same compiler. That 
> doesn't make it binutils' "fault" but it is clear that what version of 
> binutils you use produce different end results.
> 
> My concern hasn't been to find someone to put the blame on but to understand 
> what is happening and how to fix it. I personally think one has to be very 
> careful playing the blame game in an open source environment. 
> 
> I'm not suggesting it's nvidias "fault", if anything I'm grateful for them 
> providing good drivers even if they are binaries. However, I am suggesting 
> that nvidia have been caught unawares by the change and also that their 
> library wouldn't build on my (or any other gcc-3.1 + latest binutils) system.
> 
> I'm also suggesting a couple of workarounds for those who can't get opengl 
> going on their new shiny 3.1-built systems. Some have (I believe) been 
> successful in applying the patch to glibc but others haven't and for them 
> these workarounds will do the trick.
> 

Bad form on my side.  Sorry, to quick a reply after just
comming home with a long day at work behind me.  No excuse
I know.

Btw, I am almost positive it worked fine for gcc-3.0 and
binutils-2.12.


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop Team Developer
Cape Town, South Africa

Re: [gentoo-dev] libGLcore error

[Bart Verwilst]

I've added glibc-2.2.5-r4 to portage, which fixes the nvidia-glx bug and a few 
others..

See ya

On Wednesday 05 June 2002 23:23, Martin Schlemmer wrote:
|| On Wed, 2002-06-05 at 23:00, Lars Pechan wrote:
|| > Thanks a lot but I would like to think that I have put quite a big
|| > effort into finding out a) why nvidia's opengl driver doesn't work and
|| > b) how to get it working. So have others too. I also think I have a
|| > reasonable understading of what is going on.
|| >
|| > For more info on the subject see these threads in the forums:
|| >
|| > http://forums.gentoo.org/viewtopic.php?t=3701
|| > http://forums.gentoo.org/viewtopic.php?t=3963
|| >
|| > Also the following url helps in mapping out what the issues are
|| > http://sources.redhat.com/ml/libc-alpha/2002-04/msg00025.html.
|| >
|| > Also, the link you are referring to is mentioned in the forum postings.
|| >
|| > In short, yes the problem stems from the gcc-team having changed the
|| > layout of a library by hiding certain symbols. However, it's not clear
|| > whether this happened for 3.1 or in fact earlier. It did work earlier
|| > because the linker/binutils didn't care about the .hidden attribute
|| > anyway and in fact still works under 3.1 depending on what version of
|| > binutils is used.
|| >
|| > To see this happening try building one system with binutils 2.12 and one
|| > with 2.11 _both_ using gcc-3.1. The nvidia opengl driver will work on
|| > one but not the other despite both having been compiled with the same
|| > compiler. That doesn't make it binutils' "fault" but it is clear that
|| > what version of binutils you use produce different end results.
|| >
|| > My concern hasn't been to find someone to put the blame on but to
|| > understand what is happening and how to fix it. I personally think one
|| > has to be very careful playing the blame game in an open source
|| > environment.
|| >
|| > I'm not suggesting it's nvidias "fault", if anything I'm grateful for
|| > them providing good drivers even if they are binaries. However, I am
|| > suggesting that nvidia have been caught unawares by the change and also
|| > that their library wouldn't build on my (or any other gcc-3.1 + latest
|| > binutils) system.
|| >
|| > I'm also suggesting a couple of workarounds for those who can't get
|| > opengl going on their new shiny 3.1-built systems. Some have (I believe)
|| > been successful in applying the patch to glibc but others haven't and
|| > for them these workarounds will do the trick.
||
|| Bad form on my side.  Sorry, to quick a reply after just
|| comming home with a long day at work behind me.  No excuse
|| I know.
||
|| Btw, I am almost positive it worked fine for gcc-3.0 and
|| binutils-2.12.

-- 
Bart Verwilst
Gentoo Linux Developer, Desktop Team
Gent, Belgium

Re: [gentoo-dev] libGLcore error

[Adam Torgerson]

> Two phased workaround:

A better way to get around this is to patch glibc as discussed here:

http://forums.gentoo.org/viewtopic.php?t=3963

adam

Re: [gentoo-dev] libGLcore error

[Lars Pechan]

Only problem is that people are having problems applying that patch. See 
Brandon's message in this very thread.

Besides, I personally think patching glibc is quite a major affair and would 
rather wait for patch to appear in a generic, tested, properly released glibc 
but that's my personal preference and may not apply to eveyone.

On Wed, 05 Jun 2002 13:40, Adam Torgerson wrote:
> > Two phased workaround:
>
> A better way to get around this is to patch glibc as discussed here:
>
> http://forums.gentoo.org/viewtopic.php?t=3963
>
> adam
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev