Problems running kinit on HP-UX 11.00, 11i

[Albert Chin]

On Thu, May 12, 2005 at 04:51:22PM -0400, Ken Raeburn wrote:
> On May 12, 2005, at 14:20, Albert Chin wrote:
> >I built krb5-1.4.1 on HP-UX with CC=cc CFLAGS="-g -Ae +DAportable".
> >Running kinit gives the following:
> >  $ kinit
> >  Assertion failed: i->did_run != 0, file ../../include/k5-platform.h, 
> >line 232
> >  Abort(coredump)
> 
> This indicates that the k5_once macro isn't doing its job correctly.  
> One possible reason might be if the native C library provides a stub 
> for pthread_once that never calls the indicated function.  Could you 
> check on that and let me know?

On HP-UX 11i:
  $ swlist -l fileset | grep -i 'libc cumulative patch'
  # PHCO_27434                            1.0            libc cumulative patch 

  $ nm /usr/lib/libc.sl | grep pthread_once
  ___pthread_once     |   1171160|extern|code   |$CODE$
  pthread_once        |   1171144|extern|entry  |
  pthread_once        |   1171160|extern|code   |$CODE$

>From HP's patch description of PHCO_22923:
  On  HP-UX  if  a   nonthreaded   application   links   to  a
  thread-safed  library  the link will fail due to  unresolved
  pthread symbols.To resolve these symbols, it is necessary to
  link the  nonthreaded  application  to the  threads  library
  libpthread.But linking to that library makes the application
  threaded  even if it creates no  threads.Providing  POSIX 1c
  thread  "stubs" in HP-UX C language  library have two direct
  effects for  nonthreaded  applications.  a) POSIX 1c threads
  symbols are resolved if a nonthreaded application links to a
  thread-safed  library  b)We  avoid  the  overhead  of a real
  threads library -- especially the overhead  associated  with
  mutexes when the nonthreaded  application  uses thread stubs
  rather than real threads library procedures.

  Resolution:
  Stubs are provided for all pthread calls only in SHARED LIBC
  FLAVORS of the HP-UX C Library.  These stubs do not have any
  functionality,  these are  dummy  functions  returning  zero
  except  pthread_getspecific()  family of APIs which has full
  functionality  implemented in the stubs.  Full functionality
  is provided in the stub for the  following  pthread  calls
   * pthread_key_create()
   * pthread_getspecific()
   * pthread_setspecific()
   * ptherad_key_delete()
   * pthread_exit()
  call to stub pthread_self() returns 1
  call to stub pthread_equal(arg1, arg2) will return
  (arg1 == arg2)
  Call to the stub pthread_create() and pthread_attr_init()
  returns ENOSYS.
  All other stub calls returns zero.
  There are two special  interfaces  provided  for checking
  whether an application is linked to pthread library or not.
  a)  __is_threadlib_linked()
      returns 1 for an applications linked to pthread
      library otherwise returns zero.
  b)  __get_ismt()
      returns 1 for applications linked with libcma
      returns 2 for applications linked with libpthread
      otherwise returns 0

  Risks:
  ------
  An application may  inadvertantly  pick up the stubs when it
  intended  to use the real  pthreads  APIs, or it may pick up
  the  stubs  when it needs cma APIs or stubs.  These  are all
  link order problems.  An application that needs cma behavior
  must link to libcma (or the cma stubs  library)  and must do
  so in a supported link order,
  i.e.  the link line  should be shared only and should
  not contain "-lc" before -lcma.
  So long as this  condition is met, the correct cma functions
  will be referenced.  Similarly, a multithreaded  application
  that needs pthread  threads  library  behavior  must link to
  libpthread  and must do so in a  supported  link  order, and
  only use shared libc and libpthread.
  eg : An applications wants to use pthread stubs then
  the link order should be
  $ cc test.c -lc -lpthread
  An applications wants to use pthread library then the
  link order should be
  $ cc test.c -lpthread -lc
  JAGab69119; SR 8606102984

If I relink kinit with -lpthread, it works, mostly:
  # /opt/TWWfsw/krb5141/bin/kinit Administrator at AD.IL.THEWRITTENWORD.COM
  kinit(v5): Cannot resolve network address for KDC in requested realm
  while getting initial credentials

-- 
albert chin (china at thewrittenword.com)