"Nathan J. Williams" <nathanw@wasabisystems.com> writes:

> The right thing here is for libc to export its thread-operation
> stubs as pthread functions, and then to make SDL-image and similar
> libraries not link directly against libpthread, but let the libc stubs
> satisfy their mutex-locking needs until and unles the library is
> linked into a threaded application. This prevents pulling
> libpthread.so into unwary applications, which as you've seen, has all
> sorts of failure modes.
> 
> Or, to put it another way, you should wait until we fix this :) I'll
> have a go at it over the weekend and should be able to have something
> done by Monday.

Okay, it's Tuesday and I don't have a good fix for this yet. Let me
explain where I am.

 1) The SDL library, among its other features, presents applications
    with a "portable" wrapper around a few simple thread operations
    (create/join, mutex lock/unlock, condvar wait/signal). On NetBSD
    it is using libpthread as the backend for these operations. This
    means that SDL-using applications need to have libpthread linked
    in, explicitly or implicitly. The SDL shared library object does
    not have a recorded dependance on libpthread.so, so applications
    need to be explicit.
 
 2) The sdl-config script tells SDL-using applications what compiler
    and linker flags to use to get SDL. At the moment, it includes
    -lpthread. However, library extensions to SDL, like SDL-image,
    also use sdl-config and as a result the shared objects end up with
    recorded dependancies on libpthread.so.

 3) p5-SDL is a bunch of glue between Perl and some of the SDL
    interfaces. Notably, though, it doesn't expose SDL's thread
    features. This more-or-less makes sense, as I understand it,
    because Perl has its own (optional, currently disabled) thread
    layer, and threading behind the back of the Perl interpreter
    you're glued into is probably a bad idea. However, because of
    point (2), libpthread.so gets pulled in, even though it's not
    going to be used at all.

 4) Since perl uses dlopen() to get at SDL_perl.so, it dynamicaly
    activates libpthread, which leads to the previously mentioned
    lossage inside the libc thread stubs. "boom".



I think the right point of attack is (2). Random SDL add-on objects
shouldn't need libpthread linkage.

The best way to accomplish this would be to tweak the build systems so
that the random add-ons get a different set of libraries from
sdl-config. I'm not sure how feasable this is; I'd rather be
compatible with the rest of the world and not force us to keep a lot
of local patches to the build systems of all these weird libraries.

The second-best approach would be to make SDL itself not build against
libpthread at all but use libc stubs... although this would have to
include functions like pthread_create() that would have to fail as a
stub routine. This would mean that we would have to adjust the build
system of SDL-using *applications* to explicitly add -pthread or
-lpthread in order to successfully run if they actually use the thread
interface of SDL. This is a little worrisome because failing to link
against libpthread would produce a run-time error (assertion in libc
pthread_create() stub) rather than a link-time error.

        - Nathan