Subject: Re: libpthread busted?
To: None <email@example.com>
From: Nathan J. Williams <firstname.lastname@example.org>
Date: 03/05/2003 17:42:04
Thor Lancelot Simon <email@example.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.