On Oct 4, 2005, at 13:33, jimg wrote:
I am trying to get MIT kerberos 1.4.2 to run on an HPUX 11.11 box.
The
make check fails with this:
Thanks for the build info; I think that's given me a clue to what
might be going wrong.
Could you please check in the "config.cache" file in the top of the
build tree -- I suspect krb5_cv_pragma_weak_ref is set to "no".
The thread support is kind of a twisty maze of macros at the moment,
because not only do we need to support pthreads versus Windows
threads versus non-threaded systems, but in the POSIX (pthreads)
case, we also want to have one library support both multi-threaded
and single-threaded programs when possible. On platforms where weak
references are available (with a pragma, usually), we can take the
address of a symbol and compare it against NULL... except on those
systems that provide "stubs" for some pthreads routines in libc,
which stubs often don't do anything, which is the wrong thing to do
for pthread_once, so we also have to test if pthread_once appears to
be available and correctly implemented, etc.
But since -DHAVE_PRAGMA_WEAK_REF=1 isn't in your compilation line, I
expect that means that our configure script didn't figure out a way
to do weak references on HPUX 11. In that case, we should just be
requiring that the thread library always be linked in, listed in the
various library dependencies, etc. Unfortunately, there may well be
cases where we don't implement that correctly, and where most of our
UNIX test platforms are ELF platforms, non-ELF platforms like HPUX
and AIX 5 are likely to suffer.
> Assertion failed: k5int_i->did_run != 0, file error_message.c,
line 136
This basically means that the code thought it could just call
pthread_once and everything would be okay, but it called
pthread_once, and it didn't run the indicated function. This usually
means it's one of those platforms with a no-op stub function, which I
think isn't POSIX-compliant. (As I understand it, POSIX says either
you define a certain feature-test macro or not; if you do,
pthread_once exists and behaves a certain way; if you don't, either
pthread_once exists and behaves a certain way, or it doesn't exist.
If my analysis is correct, then when you compile and link without the
thread library, like MIT krb5 does, the routine exists, and doesn't
behave in the specified way. But that's okay, typically there are
certain compiler flags you need to give for ANSI/ISO/POSIX/XOpen/
whatever compliance, and they often switch off things that some
developers are going to want, so in general we don't want such
flags. In this case, use of the thread library would appear to be
one such flag. But, I digress....)
If libraries can indicate dependencies on other libraries on HPUX, we
should have at least the krb5support library, if not all of our
libraries, listing the thread library. And if that's not enough, our
programs should all be getting linked against the thread library
(using "-pthread", under gcc).
I don't know how familiar you are with debugging HPUX-specific
things; I'm not, particularly. Could you see if you can find whether
the com_err and krb5support libraries have any library dependencies?
If there's "ldd" or an equivalent, does a thread library get loaded
when the test_et program is run?
In src/aclocal.m4, around line 150 or so, we tweak things on AIX and
Tru64 (OSF/1) to pull in the thread support always, but on HPUX we're
just tweaking CFLAGS. It may be that we should treat HPUX 11 like
AIX and Tru64. (I think I added the current "hpux*" case while I was
doing a little testing on an HPUX 10 box with no pthread library
installed.) If you want to try changing that, run util/reconf from
the src directory (you'll need a recent autoconf available), re-run
configure in a fresh tree (or run "make clean"), and rebuild everything.
Ken
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
