[cairo] Recent commit of pthread support in configure.ac src/cairo-image-surface.c src/cairoint.h src/cairo-png.c src/cairo-surface.c

[Jamey Sharp]

On Fri, Feb 19, 2010 at 10:43 AM, Benjamin Otte <otte at redhat.com> wrote:
> The problem was that there were undefined symbols for apps that did not
> link against libpthread. I think those related to the recursive mutex
> functions - like pthread_mutex_setattr().

POSIX recursive mutexes are an awfully big hammer. It's been my
general experience that restructuring code to no longer need them
makes that code better. Of course, YMMV.

The pthread-stubs library doesn't include pthread_mutexattr_settype
because nobody needed it before. Nobody's asked that it be added to
glibc, either, and the glibc folks are not shy about adding stubs.

> Then of course there's the problems I've run into when dlopen()ing libs
> linking against libpthread. (See the recent dicussion about libgobject
> linking against pthread.)

Yes, that is not going to work reliably on glibc systems, or many
others with thread support either. Don't dlopen libraries that link
against pthread without linking against it yourself. It's an entirely
unsatisfying answer but AFAICT that's the best anyone can do today.

> Then there's the problem that pthread-stubs is not some well-supported
> library but just a hack, so bugs are to be expected.

Every X app on your desktop transitively depends on pthread-stubs
today, which I think is a substantial improvement over the previous
situation: there have been similar "hacks" scattered through many
different libraries for years. If pthread-stubs has bugs, for
goodness' sake, report them, because they're affecting a lot of
people.

Be aware, though, that on a glibc system such as the one you're
presumably using, pthread-stubs does not generate any code at all,
since glibc already has all the same stubs. On those systems it is a
complete no-op at link time. Code that doesn't exist is rarely buggy,
yeah? :-)

Jamey