Thor Lancelot Simon <tls@rek.tjls.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
> future.

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.

        - Nathan