On Wed, Mar 05, 2003 at 12:20:27PM -0500, Nathan J. Williams wrote:
> Thor Lancelot Simon <tls@rek.tjls.com> writes:
> 
> > >     The SDL shared library object does not have a recorded
> > >     dependance on libpthread.so, so applications need to be
> > >     explicit.
> > 
> > This seems like a very obvious bug.
> 
> I'm not so sure. Given that the supported way of including SDL in an
> application is via "cc `sdl-config --cflags` app.c `sdl-config
> --libs`", it's not clear that there's value to library dependancies.

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).

> 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.

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.

Thor