Re: [PyOpenGL-Users] pyopengl nvidia and libc.

[Rene D. <il...@ya...>]

Hey,

glxgears would run.  However that doesn't use dlopen.  It is linked with 
pthread if that makes a difference.  Which is why I think it is related 
to the libc thing mentioned in the nvidia faq. 

I checked with ldd to see if pthread was linked with the pyopengl  .soS  
and it wasn't.  Which is probably a bug in pyopengl, as it is not 
respecting the python2.3 makefiles LIBS.  However it does respect the CC 
in the python2.3 makefile(which happens to be gcc -pthread).  I tried 
linking with pthread, and without pthread, with still the same error.

Both GLcore, and dri were commented out.

What I was thinking is to somehow tell pyopengl to use dlopen on a 
specific gl driver.  For example like quake2/hexen2 used to do with a 
symlink to mesa.  But I am sure the tls libraries are there for a 
reason, just that the system seems kind of kludgey.  Too many damn 
thread implementations on linux ;)

Perhaps something like this:

try:
    import GL__init___normal
except:
    try:
        import GL__init___nottls
    except:
        import GL__init___mesa

Where it tries the normal linker determined version, then tries to load 
non tls directly ie /usr/lib/libGL.so.  If that fails try and load mesa.

This could be useful for having mesa sticking around somewhere as a 
backup on windows too.  If they do not have an opengl capable system.





Joe Connellan wrote:

> Hi Rene, can you run other openGL apps?
>
> you may have done this already but make sure you've commented out the 
> following lines in your /etc/X11/XF86Config file when using nvidias 
> XFree86 drivers
> Load  "GLcore"
> Load "dri"
>
> they are in the "Module" section
>
> I'm not positive this will fix your problem but GLcore.so lives in 
> /usr/lib/tls and since it appears deleting this file may have fixed 
> your problem it could be related, though without doing this in the 
> XFree86Config file the problem may arise again when installing new 
> drivers, or possibly break something if you change video cards or want 
> to go back to the standard nvidia ("nv") xfree drivers.
>
> hope that helps,
>
> Joe
>
>> From: Rene Dudfield <il...@ya...>
>> To: pyo...@li...
>> Subject: Re: [PyOpenGL-Users] pyopengl nvidia and libc.
>> Date: Thu, 06 Nov 2003 13:56:19 +1000
>>
>> After much playing around, it seems something which works is to rm 
>> -rf /usr/lib/tls/libGL*
>>
>> Not sure who report the bug to.  I guess nvidia.  However they 
>> haven't responded in the past, so hopefully it'll just get fixed.
>>
>>
>>
>> Rene Dudfield wrote:
>>
>>> Hello,
>>>
>>> anyone had the misfortune of comming accross a problem using 
>>> pyopengl with nvidia drivers on linux?  I think it has something to 
>>> do with a recent libc.
>>>
>>> The error I get is:
>>>  File "/usr/lib/python2.3/site-packages/OpenGL/GL/GL__init__.py", 
>>> line 2, in ?
>>>    import GL__init___
>>> ImportError: libGL.so.1: cannot handle TLS data
>>>
>>> Anyone know a fix?
>>>
>>>
>>> From nvidias FAQ:
>>>
>>> Q: Some OpenGL applications (like Quake3 Arena) crash when I start them
>>>   on Red Hat Linux 9.0.
>>>
>>> A: Some versions of the glibc package shipped by Red Hat that support
>>>   TLS do not properly handle using dlopen() to access shared libraries
>>>   which utilize some TLS models.  This problem is exhibited, for 
>>> example,
>>>   when Quake3 Area dlopen()'s NVIDIA's libGL library.  Please obtain
>>>   at least glibc-2.3.2-11.9 which is available as an update from Red 
>>> Hat.
>>>
>>> I think on debian unstable it is version: 2.3.2.ds1-9.  I have no 
>>> idea if this is like the fixed redhat glibc.  I guess it will 
>>> probably be fixed in a newer version.  If this is the problem...
>>>
>>> arg, this whole TLS/threads thing is a mess.  Probably should stay 
>>> away from upgrading debian unstable for a little while if you want 
>>> to use pyopengl.
>>>
>>> I have tried enabling, and disabling pthread in the linking and 
>>> compiling stages of pyopengl, with no luck.
>>>
>>>
>>
>>
>>