Hello,

I ported our C++11 application to QNX, but occasionally I get failures when trying to lock a std::mutex which resides on
 the stack. I'm currently testing this on SDP 6.6, but I also need to support SDP 6.5. This is why we are using libstdc+
+ instead of libcpp. 

I reduced the problem to the three minimal testcases (see attached). 
The problem seems to be that std::mutex initializes its pthread_mutex by PTHREAD_MUTEX_INITIALIZER. This mutex can be on
 the stack, but PTHREAD_MUTEX_INITIALIZER is only allowed for static (non-stack) variables 
See QNX_Neutrino_RTOS_C_Library_Reference.pdf (for SDP 6.6.0), p. 2317:
"You can initialize a _statically_ allocated mutex with the default attributes by assigning
to it the macro PTHREAD_MUTEX_INITIALIZER or
PTHREAD_RMUTEX_INITIALIZER (for recursive mutexes)."

Most modern OS have dropped the "statically" from the restrictons, thus libstdc++ uses PTHREAD_RMUTEX_INITIALIZER by 
default.

The workaround is to add -D_GTHREAD_USE_MUTEX_INIT_FUNC to the compile arguments. This should go 
into os_defines.h for a real fix (that's how libstdc++ does it on mingw)

Test cases: (run on the QNX 6.6.0 vmware image)

Stock SDP 6.6.0:
qcc tst_func.cpp -o tst_func -V4.7.3,gcc_ntox86_gpp -std=gnu++11 
qcc tst_loop.cpp -o tst_loop -V4.7.3,gcc_ntox86_gpp -std=gnu++11 
Both print  "std::mutex::lock caused std::system_error at i = 1 with code generic:22 meaning Invalid argument"

GCC 4.8.3 from linux-gcc-4.8.3-qnx660.tar.gz from this foundry27 project
qcc tst_func.cpp -o tst_func -V4.8.3,gcc_ntox86_gpp -std=gnu++11 
qcc tst_loop.cpp -o tst_loop -V4.8.3,gcc_ntox86_gpp -std=gnu++11 
Both print "std::mutex::lock caused std::system_error at i = 1 with code generic:22 meaning Invalid argument"

qcc tst_SyncMutexLock_r.cpp -o tst_SyncMutexLock_r
Both print "Second SyncMutexLock_r failed
Second SyncMutexUnlock_r failed"

Best wishes,
Matthias Gehre