On Wed, Mar 05, 2003 at 05:42:04PM -0500, Nathan J. Williams wrote:
> 
> 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,

Adding -lpthread to the link line for the Perl interpreter and
"enabling threaded perl" are not the same thing.  In the absence of any
_use_ of pthread features in the perl interpreter, is it not the case
that the only effect of adding -lpthread to the link line would be to
use the correct mutexes etc. in libc so that later dynamically opening
objects that _did_ use threading would be safe?

I've got to believe that an application that fails *just because of
the presence of additional synchronization and mutual exclusion in 
libc* is fundamentally broken.

Thor