On Fri, Jan 8, 2016 at 7:27 PM, Andre McCurdy <[email protected]> wrote: >> +diff -Naur DirectFB-1.7.6.orig/lib/direct/os/linux/glibc/mutex.h >> DirectFB-1.7.6/lib/direct/os/linux/glibc/mutex.h >> +--- DirectFB-1.7.6.orig/lib/direct/os/linux/glibc/mutex.h 2013-12-18 >> 19:16:24.000000000 -0500 >> ++++ DirectFB-1.7.6/lib/direct/os/linux/glibc/mutex.h 2015-07-18 >> 16:57:47.178982835 -0400 >> +@@ -46,7 +46,7 @@ >> + >> /**********************************************************************************************************************/ >> + >> + #define DIRECT_MUTEX_INITIALIZER(name) { >> PTHREAD_MUTEX_INITIALIZER } >> +-#define DIRECT_RECURSIVE_MUTEX_INITIALIZER(name) { >> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP } >> ++#define DIRECT_RECURSIVE_MUTEX_INITIALIZER(name) { >> PTHREAD_MUTEX_RECURSIVE } > > This looks completely bogus. > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP initialises a pthread_mutex_t > structure and PTHREAD_MUTEX_RECURSIVE is an enum. You can't just > replace one with the other.
It indeed is bogus. I took it as a stepstone to get it compiling but in reality what we need is a portable way to initialize recursive mutex instead of _NP something like using pthread_once during lock initialization. Let me see what can be done. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
