Why weak referencing pthread_equal() in k5-thread.h?

[KAMADA Ken'ichi]

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


> 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
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread/pthread.h?rev=HEAD.
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 
> weak.

perhaps...

-- 
KAMADA Ken'ichi <kamada at nanohz.org>