Thor Lancelot Simon <tls@rek.tjls.com> writes:

> The *only* significant negative consequence is that you can't dlopen()
> libpthread and magically have libc become reentrant.  I don't think it's
> an undue burden to impose, that code that wants to run multithreaded has
> to *initialize* libc that way -- which means including libpthread on the
> link line at compile time.

This is an excellent statement of the state of affairs. 

The reason that I've been arguing that I don't want to apply this to
the perl vs. SDL_perl.so case (where the .so is not a direct user of
libpthread, but just depends on feature A of a library B which also
has code for threaded feature C sitting around like a lump) is that
the part of the perl build system that pulls in -lpthread ("enabling
threaded perl") has all sorts of Danger! Experimental! labels on it,
and perl is an important enough tool that pulling in libpthread all
the time for what I percieve as an aesthetic correctness issue seems
like a bad trade-off.

I'm quite willing to declare that our standard perl won't be permitted
to load threaded extension libraries; if there is really a need for
them, the right answer is probably a separate perl-threaded package.

This still leaves the problem that subsidiary libraries like SDL-image
*really* don't need libpthread at all, but are currently coerced into
doing so by sdl-config, the usage of which doesn't seem to distinguish
between building a subsidiary library and building an application.

        - Nathan