[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoconf, sendmail, and pthreads
From: |
Ruslan Shevchenko |
Subject: |
Re: autoconf, sendmail, and pthreads |
Date: |
Thu, 21 Dec 2000 19:10:34 +0200 |
Bob Friesenhahn wrote:
>
> On Thu, 21 Dec 2000 address@hidden wrote:
> >
> > -pthread -- is for gcc
>
> Support for -pthread in gcc is non-standard. It is not supported by
> the standard GNU compiler (e.g. 2.95.2) when configured and compiled
> from distributed sources.
>
1. For Sun Solaris we can ommit this, but it is nesessorry for
FreeBSD, becouse gcc 2,95.2 which come with system is patched
for using of this option.
> The portable way to support POSIX threads for SunOS 5.6 and later is
> to add -D_REENTRANT to the compilation defines, and -lpthread to the
> libraries. Use of -lposix4 is optional, and is not necessarily
> required in order to use -lpthread. See the threads(3t) manual page.
>
> >
> > 1. I can test this on Solaris 2.6 with Sun CC 4.2
> >
> >
> > 2. I can tell 3 cases:
> > 1. Solaris and GCC -- then we must:
> > 1. define _POSIX_THREAD_SEMANTIC,
> > if gcc was configurated with --enable-threads
>
> I am not aware of the purpose of this define, and don't see it in the
> Solaris 2.6 headers. Adding -lpthreads to the link line is sufficient
> to obtain POSIX thread semantics.
>
Ok,
> > 2. Solaris and Sun C++ workshop
> > 1. add -mt flag to CFLAGS and CXXFLAGS
> > 2. define _POSIX_THREAD_SEMANTICS
>
> Adding -lpthread is sufficient to obtain POSIX thread semantics. I
> assume that this extra define (which won't work with SunOS 5.6) is
> trying to overcome the fact that -mt only adds -lthread (for UI
> threads).
>
You are right: it's not needed:
> Solaris applications that define -D_POSIX_PTHREAD_SEMANTICS get the POSIX
> semantics for these routines, but can still use the Solaris threads interface.
> It is worth noting that you can successfully (and reliably) use the
> Sun Workshop compiler with threads (while not using -mt), by following
> the same steps I described above for gcc. This allows both gcc and
> Sun Workshop to be treated the same.
>
Below is Sun docs, which fully describe compiling multithreading
programs with Sun CC .
Note, that using -mt for C++ programs is still nesessorry.
----------------------------
Preparing for Compilation
The following items are required to compile and link a multithreaded
program. Except
for the C compiler, all should come with your Solaris 2.x system.
A standard C compiler
Include files:
<thread.h> and <pthread.h>
<errno.h>, <limits.h>, <signal.h>, <unistd.h>
The regular Solaris linker, ln(1)
The Solaris threads library (libthread), the POSIX threads library
(libpthread),
and possibly the POSIX realtime library (libposix4) for semaphores
MT-safe libraries (libc, libm, libw, libintl, libnsl, libsocket,
libmalloc,
libmapmalloc, and so on)
Choosing Solaris or POSIX Semantics
Certain functions, including the ones listed below, have different
semantics in the
POSIX 1003.1c standard than in the Solaris 2.4 release, which was based
on an earlier
POSIX draft. Function definitions are chosen at compile time. See the
man Pages(3):
Library Routines for a description of the differences in expected
parameters and
return values.
Functions with POSIX/Solaris Semantic Differences
sigwait(2)
ctime_r(3C)
asctime_r(3C)
ftrylockfile(3S) - new
getlogin_r(3C)
getgrnam_r(3C)
getgrgid_r(3C)
getpwnam_r(3C)
getpwuid_r(3C)
readdir_r(3C)
ttyname_r(3C)
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.
The handling of an alarm(2) is also different: a Solaris alarm goes to
the thread's
LWP, while a POSIX alarm goes to the whole process (see Per-Thread
Alarms ;).
Including <thread.h> or <pthread.h>
The include file <thread.h>, used with the -lthread library, compiles
code that is
upward compatible with earlier releases of the Solaris system. This
library contains
both interfaces-those with Solaris semantics and those with POSIX
semantics. To call
thr_setconcurrency(3T) with POSIX threads, your program needs to include
<thread.h>.
The include file <pthread.h>, used with the -lpthread library, compiles
code that is
conformant with the multithreading interfaces defined by the POSIX
1003.1c standard.
For complete POSIX compliance, the define flag _POSIX_C_SOURCE should be
set to a
(long) value >= 199506:
cc [flags] file... -D_POSIX_C_SOURCE=N (where N 199506L)
You can mix Solaris threads and POSIX threads in the same application,
by including
both <thread.h> and <pthread.h>, and linking with either the -lthread or
-lpthread
library.
In mixed use, Solaris semantics prevail when compiling with -D_REENTRANT
and linking
with -lthread, whereas POSIX semantics prevail when compiling with
-D_POSIX_C_SOURCE
and linking with -lpthread.
Defining _REENTRANT or _POSIX_C_SOURCE
For POSIX behavior, compile applications with the -D_POSIX_C_SOURCE flag
set >=
199506L. For Solaris behavior, compile multithreaded programs with the
-D_REENTRANT
flag. This applies to every module of an application.
For mixed applications (for example, Solaris threads with POSIX
semantics), compile
with the -D_REENTRANT and -D_POSIX_PTHREAD_SEMANTICS flags.
To compile a single-threaded application, define neither the
-D_REENTRANT nor the
-D_POSIX_C_SOURCE flag. When these flags are not present, all the old
definitions
for errno, stdio, and so on, remain in effect.
To summarize, POSIX applications that define -D_POSIX_C_SOURCE get the
POSIX 1003.1c
semantics for the routines listed in Functions with POSIX/Solaris
Semantic Differences
. Applications that define only <-D_REENTRANT get the Solaris semantics
for these
routines. Solaris applications that define -D_POSIX_PTHREAD_SEMANTICS
get the POSIX
semantics for these routines, but can still use the Solaris threads
interface.
Linking With libthread or libpthread
For POSIX threads behavior, load the libpthread library. For Solaris
threads behavior,
load the libthread library. Some POSIX programmers might want to link
with -lthread
to preserve the Solaris distinction between fork() and fork1(). All that
-lpthread
really does is to make fork() behave the same way as the Solaris fork1()
call, and
change the behavior of alarm(2).
To use libthread, specify -lthread before -lc on the ld command line, or
last on the
cc command line.
To use libpthread, specify -lpthread before -lc on the ld command line,
or last on
the cc command line.
Do not link a nonthreaded program with -lthread or -lpthread. Doing so
establishes
multithreading mechanisms at link time that are initiated at run time.
These slow down
a single-threaded application, waste system resources, and produce
misleading results
when you debug your code.
This diagram summarizes the compile options:
Compilation Flowchart
In mixed usage, you need to include both thread.h and pthread.h.
All calls to libthread and libpthread are no-ops if the application does
not link
-lthread or -lpthread. The runtime library libc has many predefined
libthread and
libpthread stubs that are null procedures. True procedures are
interposed by libthread
or libpthread when the application links both libc and the thread
library.
The behavior of the C library is undefined if a program is constructed
with an ld
command line that includes the following incorrect fragment:
.o's ... -lc -lthread ... (this is incorrect)
or
.o's ... -lc -lpthread ... (this is incorrect)
Note -
For C++ programs that use threads, use the -mt option, rather than
-lthread,
to compile and link your application. The -mt option links with
libthread and
ensures proper library linking order. Using -lthread might cause your
program
to core dump.
Linking with -lposix4 for POSIX Semaphores
The Solaris semaphore routines, sema_*(3T), are contained in the
libthread library. By
contrast, you link with the -lposix4 library to get the standard
sem_*(3R) POSIX
1003.1c semaphore routines described in Semaphores .;
> Bob
> ======================================
> Bob Friesenhahn
> address@hidden
> http://www.simplesystems.org/users/bfriesen
- autoconf, sendmail, and pthreads, Lars Hecking, 2000/12/19
- Re: autoconf, sendmail, and pthreads, Steven G. Johnson, 2000/12/20
- Re: autoconf, sendmail, and pthreads, rssh, 2000/12/21
- Re: autoconf, sendmail, and pthreads, Bob Friesenhahn, 2000/12/21
- Re: autoconf, sendmail, and pthreads,
Ruslan Shevchenko <=
- Re: autoconf, sendmail, and pthreads, Bob Friesenhahn, 2000/12/21
- Re: autoconf, sendmail, and pthreads, Steven G. Johnson, 2000/12/21
- Re: autoconf, sendmail, and pthreads, Ganesan Rajagopal, 2000/12/21
- Re: autoconf, sendmail, and pthreads, Steven G. Johnson, 2000/12/21