[Date Prev][Date Next]
Re: 2.0-alpha and Solaris 7
On Sun, 15 Aug 1999, Kurt D. Zeilenga wrote:
> >The manpage says we should use -lpthread as well.
> From my reading of the Solaris programming guide, we shouldn't use '-mt'
> at all this provides Solaris semantics instead of Pthread semantics.
Ack; the cc(1) man page from SunPRO C 4.0 (on an old Sol2.5.1 box) says that
"-mt" just passes -D_REENTRANT and appends -lthread. According to the Sol7
Multithreaded Programming Guide:
"-mt" is mainly for C++ apps, straight C apps can live without it. Further,
it states that _REENTRANT is for Solaris threading behaviour whilst
_POSIX_C_SOURCE is for POSIX threads.
It's interesting to note, though, that the pthread_create(3T) man page
includes "-mt" in the synopsis, and none of the examples use _POSIX_C_SOURCE.
> Though this effects only a few calls, we happen to use at least one of
> them, fork(). It might wise to remove '-mt' detection and rely on
> -lpthread. Any objection?
Not from me.
> I noticed the programmer's manual suggests define _POSIX_C_SOURCE and/or
> _POSIX_PTHREAD_SEMANTICS. Defining _POSIX_C_SOURCE would likely be quite
If it's fork(2) that's the concern, then which behaviour is required:
"The Solaris fork(2) function duplicates all threads (fork-all behavior),
while the POSIX fork(2) function duplicates only the calling thread
(fork-one behavior), as does the Solaris fork1() function."
If "fork-one" behaviour is required, then surely all POSIX-compliant platforms
would support _POSIX_C_SOURCE?
> I am not sure what _POSIX_PTHREAD_SEMANTICS does on Solaris...
"Solaris applications that define -D_POSIX_PTHREAD_SEMANTICS get the POSIX
semantics for these routines, but can still use the Solaris threads
(See further up the page at the URL given above for semantic differences.)
> Also, we need to know what effect defining _REENTRANT has on Solaris when
> using <pthread.h> and -lpthread. Undefining _REENTRANT would likely be
Clearly it's not fatal - the Solaris man pages use _REENTRANT rather than
_POSIX_C_SOURCE, so it boils down to what behaviour is required by OpenLDAP.
> >-lrt (or obsolete alias -lposix4)
> Older Solaris, IIRC, only had -lposix4 but it's sched_yield() was
> only a stub. On such systems, we now detect and use thr_yield().
Solaris 2.5.1 and 2.6 have a distinct -lposix4, but no -lrt. No idea if
sched_yield() is a stub in them or not. Solaris 7 has -lrt, with -lposix4
just a symlink to -lrt.