See wip/MesaLib-dri/patches/patch-[ch].  It seems now that they're
actually using locking now, and thus libGL is no longer merely
thread-safe.

I'm wondering what the proper way is to handle this.  I have to worry about:

-- libGL itself
-- The same code that is used within modular X.org

In the latter case, the module is loaded with dlopen().  If I use
dlopen.buildlink3.mk/pthread.buildlink3.mk as needed, I'm worried
about massive breakage, especially with libGL.

Does this mean that every application which links against libGL will
have to link against libpthread?

Of course, I could just let it use the no-op stubs, but I'd like to
take advantage of this, as the locks added thusfar are for stability's
sake, AFAIK.

Any ideas how I should proceed?  Of course, we could take this as an
omen that we have to get on the ball about developing the "new" pkgsrc
pthread support.  Joerg: I looked in the dragonfly source tree and
really like what you've done there.  IMHO, we should have a discussion
about what to do on NetBSD, as our current thread stubs
implementation, e.g. the macros, has caused me enough headaches
already.

Regards,

--Blair