1. Clarification: -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT should be
specified explicitly. During linking, -lpthread should be specified explictly.
/kristofer
On Mon, 31 Mar 2003, Spinka, Kristofer wrote:
> 1. It's an out of date, and Solaris-biased (as opposed to POISX), man
> page. Even on
On 31/3/03 20:59, "Jeff Trawick" <[EMAIL PROTECTED]> wrote:
> I'm using Sun WorkShop 5.0 sometimes, and these builds result in
> executables like httpd referencing libthread but not libpthread.
> We pass cc the -mt switch, but at least with this version that switch
> isn't enough to pull in libpth
1. It's an out of date, and Solaris-biased (as opposed to POISX), man
page. Even on Solaris 9.
http://docs.sun.com/source/816-2454/cc_ops.app.html#pgfId-25
A.3.42 -mt
Macro option that expands to -D_REENTRANT -lthread. If you are doing your
own multithread coding, you must use this opti
Spinka, Kristofer wrote:
To be sure that the compiler is respecting the POSIX behavior, remove
the "-mt" and add "-D_POSIX_C_SOURCE=199506L" and link with -lpthread.
"man pthread_create" says "cc -mt foo.c -lpthread"
_POSIX_C_SOURCE=199506L sounds like something to force my program to use
only t
The -mt compiler option only instructs the C++ compiler to perform some
multithread safe checks and preserve a specific linking order with the
Solaris thread library.
On Solaris, the POSIX thread library is an abtraction of Sun's native
thread support. So any application that wishes to use th
I'm using Sun WorkShop 5.0 sometimes, and these builds result in
executables like httpd referencing libthread but not libpthread.
We pass cc the -mt switch, but at least with this version that switch
isn't enough to pull in libpthread. Can anybody confirm that with a
more recent Sun compiler AP
