Thread: Re: [PyOpenGL-Users] pyopengl nvidia and libc.
Brought to you by:
mcfletch
From: Joe C. <joe...@ho...> - 2003-11-06 05:38:46
|
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. >> >> > > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >PyOpenGL Homepage >http://pyopengl.sourceforge.net >_______________________________________________ >PyOpenGL-Users mailing list >PyO...@li... >https://lists.sourceforge.net/lists/listinfo/pyopengl-users _________________________________________________________________ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp |
From: Rene D. <il...@ya...> - 2003-11-06 06:21:46
|
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. >>> >>> >> >> >> |