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
Hi,
The WIN32 version of apr_file_dup is missing the create_mutex call.
This make duplicated file unusable (the ap segfaults) if opened
with APR_APPEND flag.
Here is the patch:
RCS file: /home/cvspublic/apr/file_io/win32/filedup.c,v
retrieving revision 1.54
diff -u -3 -r1.54 filedup.c
--- filedu
Index: srclib/apr/tables/apr_tables.c
===
RCS file: /home/cvspublic/apr/tables/apr_tables.c,v
retrieving revision 1.46
diff -u -r1.46 apr_tables.c
--- srclib/apr/tables/apr_tables.c 1 Jan 2003 00:01:55 - 1.46
+++ srclib/
At 07:42 PM 3/30/2003, Justin Erenkrantz wrote:
>--On Sunday, March 30, 2003 7:31 PM -0600 "William A. Rowe, Jr." <[EMAIL
>PROTECTED]> wrote:
>
>>No... I like the every-other thought. I'd go odds-devel/evens-release.
>
>And, what exactly is a odds-devel release?
>
>To clarify, what has been sugge
--On Sunday, March 30, 2003 7:31 PM -0600 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
No... I like the every-other thought. I'd go odds-devel/evens-release.
And, what exactly is a odds-devel release?
To clarify, what has been suggested for the odds/even policy is this:
1.0.0:
1.0.1:
1.0.
At 06:00 PM 3/30/2003, Justin Erenkrantz wrote:
>IIRC, there was some sentiment to burn every other minor patch number until we
>hit 1.0. So, there would be no 0.9.2 only 0.9.2-dev and 0.9.3. I'm very
>uncomfortable with such a scenario (what's the point of -dev then?). It just
>doesn't make
--On Friday, March 28, 2003 12:35 PM -0600 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
No, the discussion below is the question;
"Should release 0.9.x follow after 0.9.x-dev? Or shouldn't
we release 0.9.(x+1) following the efforts in 0.9.x-dev?"
The standing issue is this; libapr.so.0.
12 matches
Mail list logo
