[OE-core] [PATCH 24/53] directfb: Fix build with musl

[Khem Raj]

On Fri, Jan 8, 2016 at 7:27 PM, Andre McCurdy <armccurdy at gmail.com> 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.