Odd error on make check

[Ken Raeburn]

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