On Wed, 5 Mar 2003, Thor Lancelot Simon wrote:

> On Wed, Mar 05, 2003 at 12:20:27PM -0500, Nathan J. Williams wrote:
> > Thor Lancelot Simon <tls@rek.tjls.com> writes:
> >
> > 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).

That's only partially what is happening. The idea is to have the library
link against symbols that while nominally in libpthread, are really in
both libpthread and libc. libpthread has the real threaded ones, and libc
has the non-threading stubs. We do this since this lets one libc work for
both threaded and non-threaded apps. The alternative is to have something
like libc_r or some other "I'm explicitly for threads libc."

Yes, we are using the presence of libpthread (and it linking in before
libc) as a behavior modifier, but it really is. That's how you know if
you're threaded or not.

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

Well, that's not what's going on here. The SLD folks wanted to make a
library that, if it's used in a threaded app, will work right, and if it's
used in a non-threaded app, will ALSO work right.

Note that the SLD library is only trying to be thread-safe, not
necessarily threaded. If it were really threaded, I'd agree 100% that if
you're loading it you should only do that in a threaded app. But it's only
trying to do what our libc also does.

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

But (as I understand our Perl install), the _Perl_ modules don't use
threading. It's just that p5-SDL is using libraries that MIGHT be used in
a threaded environment, even though it isn't itself threaded. Thus the
rub.

I actually think what Nathan is doing is the right thing. If we don't do
something like this exposing_names_from_libpthread_yet_letting_
libc_satisfy_link_references trick, we will need two of each library that
needs to be thread-savy when we're in a threaded environment; one with
thread hooks and one w/o. Since libc is one such library and almost all
libraries reference it, that means we would really need two of almost
EVERY library, with one having the references to libc and the other having
references to libc_r or whatever.

That sounds like a royal mess.

Take care,

Bill