Subject: Re: libpthread busted?
To: Peter Seebach <>
From: Nathan J. Williams <>
List: current-users
Date: 03/04/2003 22:46:43
"Nathan J. Williams" <> 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
> 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, 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

 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), gets pulled in, even though it's not
    going to be used at all.

 4) Since perl uses dlopen() to get at, 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