Assertion failed for krb5kdc
Ken Raeburn
raeburn at MIT.EDU
Mon Oct 19 20:46:20 EDT 2009
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
More information about the Kerberos
mailing list