Re: 2.0-alpha and Solaris 7

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:53 AM 8/14/99 +1000, David J N Begley wrote:
>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

Does anyone know if the current tests work with the vendor's C compiler?
	(I suspect the "-mt" is used).

Does anyone know what the vendor compiler does with:
	-mt, -pthread, -kthread, etc?

Which tests are "yes" and which are "no" when preceeding tests are disabled?

What does GCC do with -mt, -pthread, -kthread, etc?

>From my reading of egcs specs, I would think that -pthreads or
-threads would work.  I don't have gcc 2.8 handy.  Can you run
configure repeatingly each time forcing another test to no until
you get a compat success?

>- 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

I believe we at least fixed pthread detection when the vendor's
compiler is used.  Some versions (or derivities of GNU cc) may
also work.

>  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).

I trust that you have complained to your vendor.

> 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.

   e.  improve the test.

Can you keep to see which pthreads routines are NOT stubbed in libc?
(I rather extend our AC_TRY_LINK test then have to resort to
AC_TRY_RUN test).

>  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 should be noted that under AIX we only attempt to choose the
appropriate vendor compiler when the user has selected pthreads
and did not specify a compiler.  An AIX user who chooses a compiler
is left on their own.

Solaris has no "special" compiler, but a "special" flag (-mt).
We support this.

Linux gets no specific special attention.  However, we do check
to see if the pthread support which was detected is LinuxThreads.
LinuxThreads may exist on non-Linux boxes... you could even port
it to Solaris if you wanted to.


>  # 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

And what if we using CC=gcc LIBS=-lmypthreads?
or CC=gcc-with-work-pthreads-flag ?
or CC=who-knows-what ?

Does the -mt test fail under gcc?
If so, why does the -kthread test not fail.  I would assume
this would either work or generate an error which would cause
the test to fail.

>  Is there any particular reason for the threads detection code used by
>  configure at present?

Yes.  The configure script detects based upon what is available in
environment and not what what we guess is available.  To support
cross compiling, AC_TRY_RUN tests should be avoided.

>- Problem #2: symbol inet_aton not found linking slapd

This was fixed in devel, I believe.  (though we still need to
recode to use the internal inet_aton routine in a few places).

>  The problem was in fact that "-lresolv" wasn't even being
>  linked at all to slapd.

A new -lresolv test is in the works.

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

Thanks for the feedback.   It will likely be a few days before
alpha2 is cut.

Kurt