Subject: Re: libpthread busted?
To: None <email@example.com>
From: Nathan J. Williams <firstname.lastname@example.org>
Date: 03/05/2003 13:49:34
Thor Lancelot Simon <email@example.com> writes:
> As far as I can see, it is quite simply and obviously a bug for a library
> to contain references to symbols from another library but not record a
> dependency on that library, regardless of what Special Process is used
> for linking (SDL magic, libfool, etc).
I don't believe we have an actual policy on this subject. It's in the
same category of aesthetic/religious debate as whether a C source
header should #include all of its prerequisite headers or make the
application #include them first.
> > Having SDL contain a recorded dependance on libpthread.so would make
> > the p5-SDL problem more difficult; perl really has no interest in
> > dynamically loading libpthread.so.
> It seems to me that any executable that wishes to dlopen() objects that
> may reference pthread functions *is inherently a threaded application*
> and must, therefore, itself be linked to libpthread at compile time. Any
> method of hiding the fact that one is changing boats mid-stream seems
> highly prone to error and highly likely to come back to bite us in the
I agree with this. It just isn't the case at hand.
> In other words, if there are Perl modules that may use threading, and
> we want to support those modules at all, we need to link libpthread into
> the Perl interpreter.
The point of the problem is that the Perl SDL module does *not* use or
export any of SDL's threading interfaces to the Perl interpreter and
therefore has no need for libpthread.