Displaying 7 results from an estimated 7 matches for "pthread_process_private".
2010 Feb 14
2
[LLVMdev] [cfe-dev] clang with pthread on mingw
...thread_rwlockattr_t if it is actually needed, rather than creating it, initialising it, not using it, and then destroying it on mingw (and, as the code currently stands, *BSD).
The code in the #ifdef just above your change is a bit strange too. Perhaps someone could explain this. It is setting PTHREAD_PROCESS_PRIVATE, which POSIX says should be the default, but seems to only be doing it on some platforms. Oddly, this is done by excluding *BSD (but not Darwin). If Linux / Darwin / Solaris / some other platforms have a bug in their pthread implementation and default to the wrong value, then it would be cleaner...
2006 Apr 17
3
[LLVMdev] OpenBSD. (Was: 1.7 Pre-Release Ready for Testing)
...; undeclared (first use this
function)
Mutex.cpp:80: error: (Each undeclared identifier is reported only once for each
function it appears in.)
78 #ifndef __FreeBSD__
79 // Make it a process local mutex
80 errorcode = pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_PRIVATE);
81 #endif
So I modified both occurrences of __FreeBSD__ to also check for
__OpenBSD__.
The next problem was INT8_MAX, etc., weren't being defined.
include/llvm/Support/DataTypes.h.in is inadequate for this platform. I
dumped a set of definitions into each file that wanted them as a bo...
2010 Feb 14
0
[LLVMdev] [cfe-dev] clang with pthread on mingw
...ockattr_t if it is actually needed, rather than creating it, initialising it, not using it, and then destroying it on mingw (and, as the code currently stands, *BSD).
>
> The code in the #ifdef just above your change is a bit strange too. Perhaps someone could explain this. It is setting PTHREAD_PROCESS_PRIVATE, which POSIX says should be the default, but seems to only be doing it on some platforms. Oddly, this is done by excluding *BSD (but not Darwin). If Linux / Darwin / Solaris / some other platforms have a bug in their pthread implementation and default to the wrong value, then it would be cleaner...
2006 Apr 17
0
[LLVMdev] OpenBSD. (Was: 1.7 Pre-Release Ready for Testing)
...> function)
> Mutex.cpp:80: error: (Each undeclared identifier is reported only once for each
> function it appears in.)
>
> 78 #ifndef __FreeBSD__
> 79 // Make it a process local mutex
> 80 errorcode = pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_PRIVATE);
> 81 #endif
>
>So I modified both occurrences of __FreeBSD__ to also check for
>__OpenBSD__.
>
>The next problem was INT8_MAX, etc., weren't being defined.
>include/llvm/Support/DataTypes.h.in is inadequate for this platform. I
>dumped a set of definitions into ea...
2006 Apr 18
1
[LLVMdev] OpenBSD. (Was: 1.7 Pre-Release Ready for Testing)
...> function)
> Mutex.cpp:80: error: (Each undeclared identifier is reported only once for each
> function it appears in.)
>
> 78 #ifndef __FreeBSD__
> 79 // Make it a process local mutex
> 80 errorcode = pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_PRIVATE);
> 81 #endif
>
>So I modified both occurrences of __FreeBSD__ to also check for
>__OpenBSD__.
>
>The next problem was INT8_MAX, etc., weren't being defined.
>include/llvm/Support/DataTypes.h.in is inadequate for this platform. I
>dumped a set of definitions into ea...
2006 Apr 17
0
[LLVMdev] 1.7 Pre-Release Ready for Testing
Hi Josephm
> I would like to test but the I modigied the configure to make unknown
> = OpenBSD and Unix and go pretty far but it died right after 'supports
> mkdir' yes...
Could that have been `checking for mkdir...'?
> then the next line was 'your system is unsupported''
Have you looked at ./config.log. ./configure creates this as it runs as
a trace of the
2006 Apr 16
2
[LLVMdev] 1.7 Pre-Release Ready for Testing
I would like to test but the I modigied the configure
to make unknown = OpenBSD and Unix and go pretty far but
it died right after 'supports mkdir' yes...
then the next line was 'your system is unsupported''
I have gcc 3.3 on OpenBSD 3.3 pro-police stack compiler...
I am only really interested in testing the C/C++ but C primarily
for my work.
regards, Joseph Altea