search for: pthread_process_priv

Displaying 7 results from an estimated 7 matches for "pthread_process_priv".

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 clean...
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...
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 clean...
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...
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...
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