Assertion failed for krb5kdc

[Ken Raeburn]

On Oct 19, 2009, at 16:55, eightball wrote:
>>   This would be dependent on some configuration macros,
>> HAVE_PRAGMA_WEAK_REF and NO_WEAK_PTHREADS; can you see which are set
>> in include/autoconf.h in the build tree?  The former should be  
>> defined
>> (based on tests of the compiler, so it may also depend on which
>> compiler you're using), and the latter should not (selected in the
>> configure script based on the OS version).
>>
>> Ken
>
> Both are set to 1.

Okay, that sounds like it's the problem.  The configure script should  
be setting the latter only for Solaris 10, unless the patterns we're  
checking for are wrong:

   case "${host_os}" in
[...]
     solaris2.[1-9])
       # On Solaris 10 with gcc 3.4.3, the autoconf archive macro  
doesn't
       # get the right result.   XXX What about Solaris 9 and earlier?
       if test "$GCC" = yes ; then
         PTHREAD_CFLAGS="-D_REENTRANT -pthreads"
       fi
       ;;
     solaris*)
       # On Solaris 10 with gcc 3.4.3, the autoconf archive macro  
doesn't
       # get the right result.
       if test "$GCC" = yes ; then
         PTHREAD_CFLAGS="-D_REENTRANT -pthreads"
       fi
       # On Solaris 10, the thread support is always available in libc.
       AC_DEFINE(NO_WEAK_PTHREADS,1,[Define if references to pthread  
routines should be non-weak.])
       ;;

Can you check the setting of the host config type?  In the build tree  
for Solaris 8 or 9, run a grep command like this:

$ grep cv_host config.cache
ac_cv_host=${ac_cv_host=i386-apple-darwin9.8.0}
krb5_cv_host=${krb5_cv_host=i386-apple-darwin9.8.0}
$

For Solaris 9, we'd expect to see something like "sparc-sun- 
solaris2.9" in there.

Oh... uh... just to check something that should've been obvious to me  
to ask before... by any chance did you:
(a) use the Solaris 10-built binaries for Solaris 8 and 9, or
(b) reuse a Solaris 10 build tree for making the Solaris 8/9 binaries,  
making "clean" and maybe reconfiguring but without getting rid of the  
"config.cache" file?

In general (a) is not good; backwards compatibility options will often  
let you do the reverse, but sometimes software built for a newer OS  
version will wind up using new features that weren't available in the  
old system.  In this case, a working pthread_once in libc.

If (b) happened, it's sort of a similar issue but a little more  
specific to the krb5 setup -- our configure script knows that Solaris  
10 has better thread support, and disables the workarounds needed for  
Solaris 9.  And configure scripts generated with "autoconf" have the  
ability to cache results of tests; I think it's disabled by default in  
modern autoconf, but our script takes a while to run so we enable it,  
and maybe it needs to do better checking to ensure that the cached  
values were actually associated with the current system type.

If you do reuse a krb5 build tree for a different OS, you should...  
hm, actually, one or two directories may get configured or not  
depending on system software available, and switching from  
"configured" to "not configured" may not work properly; I'd have to  
check.  The simplest advice is: Use a fresh build tree for each OS  
version.

Ken