2.0-alpha and Solaris 7

[David J N Begley <david@avarice.nepean.uws.edu.au>]

Folks, just a few notes on trying to build OpenLDAP 2.0-alpha on Solaris 7 for
testing;  most of this is an update on existing known problems.

Test Environ:
  OpenLDAP 2.0-alpha, Solaris 7, sun4c (SPARC), gcc 2.8.1, Berkeley DB 2.7.5

- Problem #1: OpenLDAP and Solaris threads don't like each other (saga)

  With OpenLDAP 1.x the error has been:

    pthread.h and pthread_create are not compatible

  With OpenLDAP 2.0-alpha the error has become:

    pthread_create is not usable, check environment settings

  In both cases, the cause is generally the same (Solaris' libc including
  a bogus pthread_create stub - Solaris 2.6 and 7, but not 2.5.1).  Previous
  discussions (leading to FAQ notes) has revolved around four approaches:

  a.  disable threads;
  b.  use Sun LWP's instead;
  c.  add "-lpthread -lposix4" to LIBS before running configure;  or,
  d.  preset a lot of environment variables to "no" to trick configure into
      using the correct POSIX threads configuration for Solaris.

  Approach (a) is no good if you need replication as slurpd requires threads.

  Approach (b) is iffy, given Kurt's comments in relation to ITS#249 regarding
  some Solaris systems not reclaiming LWP resources (in which case, shouldn't
  this be removed as a "viable alternative" from the FAQ?).

  Approach (c) is noted in the FAQ as being "not generally recommended", and
  besides is version specific (Solaris 2.5.1 and 2.6 have a distinct
  "libposix4" whereas Solaris 7's "libposix4" is just a symlink to "librt").

  Approach (d) is user unfriendly (even for experienced sysadmins) and is
  OpenLDAP version specific (the variable names have changed for 2.0-alpha
  so the recommended settings don't work and thus trigger the "-kthread"
  problem noted in the FAQ).

  It would be *really* nice if configure just recognised this problem and
  worked around it (after all, AIX and Linux seem to be singled out for
  special threads attention in configure - why not Solaris?  It has just as
  many bugs as the others..).  Not having autoconf on any of our Solaris
  boxen I just hacked configure to see if it would at least build the beast,
  by adding the following starting at line 6140:

  # skip tests we know will fail, jump to -lpthread
  # since sunpro c uses -mt, maybe we should not do this if CC is sunpro c
  case "$target" in
  	*-sun-solaris2.[67])
  	# should perhaps only do this for gcc/egcs
  	ol_cv_pthread_create=no
  	ol_cv_pthread_mt=no
  	ol_cv_pthread_kthread=no
  	ol_cv_pthread_pthread=no
  	ol_cv_pthread_pthreads=no
  	ol_cv_pthread_mthreads=no
  	ol_cv_pthread_thread=no
  	ol_cv_pthread_lpthread_lmach_lexc_lc_r=no
  	ol_cv_pthread_lpthread_lmach_lexc=no
  	ol_cv_pthread_lpthread_lexc=no
  	ol_cv_pthread_lib_lpthread_woff=no
  	ol_cv_pthread_lpthread=yes
  	;;
  esac

  # Solaris 7 is like Digital UNIX - sched_yield() in -lrt
  # libposix4 is a symlink to librt
  # but does it work -- who knows...
  case "$target" in
  	*-sun-solaris2.7)
  	# should perhaps only do this for gcc/egcs
  	ac_cv_func_sched_yield=yes
  	LTHREAD_LIBS="$LTHREAD_LIBS -lrt"
  	;;
  esac

  Is there any particular reason for the threads detection code used by
  configure at present?  Squid's configure (for example) just looks straight
  for "-lpthread";  would putting that test first break any other platforms?

- Problem #2: symbol inet_aton not found linking slapd

  This is ITS#244;  until the "new inet_aton" (now replaced with "inet_addr"?)
  appears on the scene (a new 2.0 snapshot, for those of us without CVS),
  this just breaks completely making it a tad difficult for Solaris 2.x users
  to test OpenLDAP 2.0-alpha.

  The comment was made that libresolv.so should be linked to libresolv.so.2
  to fix this problem - I found this was already the case on the Solaris 7,
  2.6 and 2.5.1 (recent patch cluster) machines I checked.  The problem was
  in fact that "-lresolv" wasn't even being linked at all to slapd.

- Problem #3: documentation mismatch

  After finally completing the build, the top-level INSTALL file says to run:

  cd tests
  make

  Alas, this doesn't actually achieve the desired result.  As the README in
  the "tests" subdirectory shows, you need to run:

  make test

At this point slapd core dumped upon startup, the caffeine ran out and the
sleep process gained control of the CPU.

Cheers..


dave