Hi Eric,
On Mon, Feb 14, 2011 at 03:05:49PM -0700, Eric Wasylishen wrote:
> It's caused by the thread-local fast_path_cache variable in pixman.c.
> If you make that non-thread-local (a normal static variable) the
> problem will go away.
Yep, or if you set the tls_model to *-exec. But IMO this shouldn't be
required: "global-dynamic" appears to be the right TLS model for shared
libraries. IMVHO, if something was seriously broken with pixman's (new)
TLS support, the whole world would be crashing, not only GNUstep.
> The root problem here is interaction between thread local storage and
> dlopen, because the gnustep-back bundle, which dynamically links to
> libpixman, is dlopened by gnustep-gui.
Could you please explain more about this interaction (CCing
613...@bugs.debian.org if possible)? According to pixman's upstream
maintainer, and my humble reading about the TLS documentation in GCC,
there should be no problem at all.
Can you reproduce if you configure gnustep-back with --disable-glx? I
can't, which leads me to the clue that the real culprit is mesa, which
uses __attribute__ ((tls_model ("initial-exec"))) for the thread-local
variables in libGL.so, and that's apparently incompatible.
> However, I'm not sure how to properly fix it other than building
> pixman without TLS.
Well, we have to find where the bug really lies and fix it there. I'm
afraid building pixman without TLS support is the wrong course of action
from wherever you look at it; I doubt that pixman's maintainers would be
keen on such move (and rightfully so).
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
