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

[Khem Raj]

On Fri, Jan 8, 2016 at 11:43 PM, Khem Raj <raj.khem at gmail.com> wrote:
> 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.

Please try out https://github.com/kraj/openembedded-core/commit/4104b7cdd0b58e24a926cdcf6415f3da3f48624e
which should be the right fix and portable one.