[C++-sig] Boost.Python std::cerr segfault when built with -lGL

[Gazihan Alankus]

Stefan Seefeld wrote:

> Gazihan Alankus wrote:
> 
>> Thank you for your interest. If you don't get the same error, I can run
>> any test programs, give you traces or if you prefer I can open up a user
>> account for you in my laptop so that you can ssh in.
> 
> I followed your suggested procedure, and everything seems to run fine. No
> segfault. I would expect the problem to be somewhere deep down in system
> libraries and the compiler (toolchain), not directly related to boost or
> mesa. (Mesa, as a C library, doesn't even know about std::cerr...)

I'm happy to inform everybody that I've solved this, *and* it was related to
Mesa. Here is a short overview of what went down:

When I dived into gcc's libstdc++-v3 code, I saw that operator<<() was using
std::uncaught_exception() to see whether there is an uncought exception
around, which was dereferencing what __cxxabiv1::__cxa_get_globals()
returns, which was NULL when the library was linked against libGL.so.
__cxxabiv1::__cxa_get_globals() had three cases depending on #define's
which were all about threading. I didn't know which ones were active, but I
pursued all and couldn't end up with anything better than a global
variable's pointer being NULL, which didn't make much sense. Maybe it was
an extern'ed global variable, but I'm not sure. This was where I stopped a
couple of days ago. 

This morning I wanted to go deep in Mesa, and before I did luckily I saw
that Mesa can be compiled with or without Native POSIX Thread Library
(NPTL) support and my settings in Gentoo (use flags) included +nptl. I
compiled Mesa without nptl support, and voila! cerr works perfectly fine in
my Boost.Python library! 

I'm not sure who to blame:), but I suggest this should be looked into by
Boost.Python and Mesa developers. For anyone currently experiencing this
strange bug, the solution for the time being is to compile Mesa without
NPTL support. 

-Gazi