When Mesa is built with NPTL support, Python extensions linked to libGL
segfault when std::cerr is used. Please see the following thread for
descriptions, details and sample programs: 

http://thread.gmane.org/gmane.comp.python.c++/11443/focus=11470

I can't reproduce this error on head with Ubuntu Linux/amd64 gcc 4.1.2.  What are the platform details?  OS, compiler, etc.


$ gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -I/usr/include -I/usr/local/include -I./Include -I. -c ../spam.cc -o spam.o
$ gcc -pthread -shared spam.o -L/usr/lib64 -L/usr/local/lib -Wl,-R/usr/lib64 -ldb-4.4 -o build/lib.linux-x86_64-2.6/spam.so -lstdc++
$ ./python
>>> import spam
>>> spam.system('ls')
this be cerr
big5.py               __db.003    libpython2.6.a   Objects        python-clean
build                 __db.004    LICENSE          Parser         python-fast
config.log            __db.005    log.0000000001   PC             README
config.status         Demo        Mac              PCbuild        RISCOS
config.status.lineno  Doc         Makefile         PCbuild8       setup.py
configure             Grammar     Makefile.pre     pyconfig.h     Tools
configure.in          Include     Makefile.pre.in  pyconfig.h.in
__db.001              install-sh  Misc             python
__db.002              Lib         Modules          Python
0

Please provide a failing test program or we have to close the bug. I
can't reproduce it on my x86 machine with Python 2.5 and GCC 4.2 either.

If by not being able to reproduce, you mean that you campiled Mesa 
with NPTL support and tried a Python extension that's using std::cerr 
(like the attached source in the other thread I linked to) and is 
linked to -lGL, then fine. 

Mesa with NPTL support is compiled with 

# Add '-DGLX_USE_TLS' to ARCH_FLAGS to enable TLS support.

as quoted from configuration files in config/ directory of Mesa source 
tree.

I use Gentoo, if you believe it matters.

I compiled the referenced test program on Gentoo, where my Mesa library
is compiled with NPTL:

rdmurray@partner:~>equery uses mesa
[ Searching for packages matching mesa... ]
[ Legend : Left column  (U) - USE flags from make.conf              ]
[        : Right column (I) - USE flags packages was installed with ]
[ Found these USE variables for media-libs/mesa-7.3 ]
 U I
 <snip>
 + + nptl

gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-I/usr/include -I/usr/local/include -I./Include -I. -c spam.cc -o spam.o
gcc -pthread -shared spam.o -L/usr/lib -L/usr/local/lib -Wl,-R/usr/lib
-lGL -o build/lib.linux-i686-2.7/spam.so -lstdc++
rdmurray@partner:~/python/trunk>strings build/lib.linux-i686-2.7/spam.so
|grep -i libgl
libGL.so.1
>./python
Python 2.7a0 (unknown, Mar 29 2009, 16:10:14) 
[GCC 4.1.2 (Gentoo 4.1.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import spam
>>> spam.system('ls')
this be cerrzsh: segmentation fault  ./python

Without the '-lGL' it works fine.

Now, is it a bug in Python, or Mesa?

I haven't checked if it is still a problem in py3k since spam.cc
does not compile cleanly under py3k.

Could a Linux guru try to reproduce this with the latest trunk, thanks.

I assume this was due to the following bug:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
http://lists.freedesktop.org/archives/mesa-dev/2011-March/006180.html

In short, MESA didn't use the correct TLS model for thread-local variables, which ended up in some libstdc++ thread-local variables not being initialized when called from a dynamically loaded libraries (such as spam).

I couldn't reproduce the problem on Debian testing (which has a mesa version containing the patch posted on mesa-dev).