Odd error on make check

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Odd error on make check

JimG-3
Hi,

I am trying to get MIT kerberos 1.4.2 to run on an HPUX 11.11 box.  The
make check fails with this:

+ gawk -f ./../../util/et/et_c.awk outfile=ettmp17844.c ettmp17844.et
gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DKRB5_KRB4_COMPAT=1
-DHAVE_BT_RSEQ=1 -DKRB5_PRIVATE=1 -DKRB5_DEPRECATED=1
-DKRB5_DNS_LOOKUP_KDC=1 -DKRB5_DNS_LOOKUP=1 -DHAVE_RES_SEARCH=1
-DDELAY_INITIALIZER=1 -DCONSTRUCTOR_ATTR_WORKS=1
-DDESTRUCTOR_ATTR_WORKS=1 -DUSE_LINKER_FINI_OPTION=1 -DENABLE_THREADS=1
-DHAVE_PTHREAD=1 -DHAVE_PTHREAD_ONCE=1 -DHAVE_PTHREAD_RWLOCK_INIT=1
-DHAVE_PTHREAD_RWLOCK_INIT_IN_THREAD_LIB=1 -DYYTEXT_POINTER=1
-DNO_YYLINENO=1 -DHAVE_SYS_ERRLIST=1 -DNEED_SYS_ERRLIST=1
-DHAVE_STRERROR=1 -DHAVE_STDARG_H=1 -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDLIB_H=1
-DHAVE_REGCOMP=1   -I../../include -I./../../include
-I../../include/krb5 -I./../../include/krb5 -I. -I.  -D_REENTRANT
-D_THREAD_SAFE -D_POSIX_C_SOURCE=199506L -D_REENTRANT -pthread -c
test2.c
gcc -L../../lib -Wl,+s -Wl,+b,/usr/local/lib -D_REENTRANT
-D_THREAD_SAFE -D_POSIX_C_SOURCE=199506L  -o test_et test_et.o test1.o
test2.o -lcom_err -lkrb5support
SHLIB_PATH=`echo -L../../lib | sed -e "s/-L//g" -e "s/ /:/g"`; export
SHLIB_PATH; ./test_et
Before initiating error table:

Table name 'krb'
UNIX  name ''
Assertion failed: k5int_i->did_run != 0, file error_message.c, line 136
/bin/sh: 17865 Abort(coredump)
gmake[2]: *** [check-unix] Error 134
gmake[2]: Leaving directory `/usr/contrib/src/krb5-1.4.2/src/util/et'
gmake[1]: *** [check-recurse] Error 1
gmake[1]: Leaving directory `/usr/contrib/src/krb5-1.4.2/src/util'
gmake: *** [check-recurse] Error 1
#

I would appreciate any comments or suggestions.

thank much,

jim

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Odd error on make check

Kiran Kumar M.
My guess it that the threads support has not been properly configured.
You may want to try changing the acx_pthread_flags options in all
the configure files. Start with changing -mthreads to whatever gcc
accepts to compile in threads support ( for the HP-UX ansic compiler -mt
worked )

HTH
Kiran

jimg wrote:

> Hi,
>
> I am trying to get MIT kerberos 1.4.2 to run on an HPUX 11.11 box.  The
> make check fails with this:
>
> + gawk -f ./../../util/et/et_c.awk outfile=ettmp17844.c ettmp17844.et
> gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DKRB5_KRB4_COMPAT=1
> -DHAVE_BT_RSEQ=1 -DKRB5_PRIVATE=1 -DKRB5_DEPRECATED=1
> -DKRB5_DNS_LOOKUP_KDC=1 -DKRB5_DNS_LOOKUP=1 -DHAVE_RES_SEARCH=1
> -DDELAY_INITIALIZER=1 -DCONSTRUCTOR_ATTR_WORKS=1
> -DDESTRUCTOR_ATTR_WORKS=1 -DUSE_LINKER_FINI_OPTION=1 -DENABLE_THREADS=1
> -DHAVE_PTHREAD=1 -DHAVE_PTHREAD_ONCE=1 -DHAVE_PTHREAD_RWLOCK_INIT=1
> -DHAVE_PTHREAD_RWLOCK_INIT_IN_THREAD_LIB=1 -DYYTEXT_POINTER=1
> -DNO_YYLINENO=1 -DHAVE_SYS_ERRLIST=1 -DNEED_SYS_ERRLIST=1
> -DHAVE_STRERROR=1 -DHAVE_STDARG_H=1 -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_REGCOMP=1   -I../../include -I./../../include
> -I../../include/krb5 -I./../../include/krb5 -I. -I.  -D_REENTRANT
> -D_THREAD_SAFE -D_POSIX_C_SOURCE=199506L -D_REENTRANT -pthread -c
> test2.c
> gcc -L../../lib -Wl,+s -Wl,+b,/usr/local/lib -D_REENTRANT
> -D_THREAD_SAFE -D_POSIX_C_SOURCE=199506L  -o test_et test_et.o test1.o
> test2.o -lcom_err -lkrb5support
> SHLIB_PATH=`echo -L../../lib | sed -e "s/-L//g" -e "s/ /:/g"`; export
> SHLIB_PATH; ./test_et
> Before initiating error table:
>
> Table name 'krb'
> UNIX  name ''
> Assertion failed: k5int_i->did_run != 0, file error_message.c, line 136
> /bin/sh: 17865 Abort(coredump)
> gmake[2]: *** [check-unix] Error 134
> gmake[2]: Leaving directory `/usr/contrib/src/krb5-1.4.2/src/util/et'
> gmake[1]: *** [check-recurse] Error 1
> gmake[1]: Leaving directory `/usr/contrib/src/krb5-1.4.2/src/util'
> gmake: *** [check-recurse] Error 1
> #
>
> I would appreciate any comments or suggestions.
>
> thank much,
>
> jim
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Odd error on make check

Kenneth G Raeburn
In reply to this post by JimG-3
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Odd error on make check

Kenneth G Raeburn
On Oct 6, 2005, at 16:11, Ken Raeburn wrote:
> and where most of our UNIX test platforms are ELF platforms, non-
> ELF platforms like HPUX and AIX 5 are likely to suffer.

It's been pointed out to me that AIX 5 on Itanium and HPUX 11 do use  
ELF after all.
Can you tell I haven't had a chance to use these systems yet? :-)

Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

question on keytabs

JimG-3
In reply to this post by JimG-3
Hi all,

I am working to modify a SSO app called Cosign.  I want it to try to authenticate to multiple realms.  I actually have it doing that now.  However, someone has brought up a good question.  Right now, I only have an Active Directory realm and a Unix realm.  However, if I want to add more Unix realms, how do I transfer the keytab.cosign to other KDC's.   I am thinking that a kdb5_util load update would bring it into a different kdc.  How can I dump the single principal from the original KDC?  Or is my thinking all wrong here?

Thanks much!

jim




________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: question on keytabs

Jeffrey Altman-3
Goldrick, Jim wrote:

> Hi all,
>
> I am working to modify a SSO app called Cosign.  I want it to try to authenticate to multiple realms.  I actually have it doing that now.  However, someone has brought up a good question.  Right now, I only have an Active Directory realm and a Unix realm.  However, if I want to add more Unix realms, how do I transfer the keytab.cosign to other KDC's.   I am thinking that a kdb5_util load update would bring it into a different kdc.  How can I dump the single principal from the original KDC?  Or is my thinking all wrong here?
>
> Thanks much!
>
> jim

What you need to do is exchange cross-realm keys with the other realms
whose principals you would like to be able to authenticate to your
Cosign authenticated services.

You do not want to provide the key entries associated with your cosign
installation to anyone else.  If you have done so, you should change the
keys immediately.   Anyone with access to the cosign keys can gain
access to all of the Kerberos 5 TGTs for users that have logged into
Cosign.

Jeffrey Altman


--
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos