Why weak referencing pthread_equal() in k5-thread.h?
kamada at nanohz.org
Fri May 6 11:07:38 EDT 2005
At Thu, 5 May 2005 16:25:56 -0400,
Ken Raeburn <raeburn at mit.edu> wrote:
> On Apr 12, 2005, at 20:01, KAMADA Ken'ichi wrote:
> >>> Background:
> >>> MIT krb5-1.4 (and current on Apr 6) doesn't work on NetBSD
> >>> (unless the calling program is linked with libpthread).
> I'm looking into this, and can't reproduce the problem. I'm working
> with NetBSD 2.0 on an alpha, and looking at our "kinit" and "klist"
> binaries, which don't get linked against libpthread; what version are
> you using?
I was using NetBSD-current (2.99.16 of Feb 25). Sorry for missing
> If you're using netbsd-current and they've added a stub for
> pthread_once to libc, I think that would explain the problem, and I'd
> need to know the name of a function in libpthread that they didn't add
> a stub for. I could use pthread_equal, or pthread_join, or ....
On NetBSD 2.0, there is no pthread_*() stubs in libc. If we want to
write a library which can be linked without libpthread, we need to
include <threadlib.h> and use thr_once(), mutex_lock(), etc.
(or use some magic like weak reference by the library itself).
Recent NetBSD-current (and not-yet-released 3.0) have pthread stubs
and don't have <threadlib.h> any more.
The latest declaration of pthread functions can be viewed at
Functions aliased with the CPP macros at the tail of the header file
have stubs in libc.
pthread_join(), pthread_detach(), or pthread_kill() seems to me
to be a good candidate to test on NetBSD.
> And it occurs to me that this could be a compatibility problem with
> future versions of an OS, if they add a stub for the routine we're
> testing for. Perhaps I should think about changing the code to test
> all of the functions we use, or at least all the ones we indicate are
KAMADA Ken'ichi <kamada at nanohz.org>
More information about the krbdev