[OE-core] [PATCH] libnl: musl fixes

[Khem Raj]

> On Aug 12, 2016, at 12:42 AM, André Draszik <git at andred.net> wrote:
> 
> On Fri, 2016-08-12 at 00:28 -0700, Khem Raj wrote:
>> On Fri, Aug 12, 2016 at 12:26 AM, André Draszik <git at andred.net> wrote:
>>> 
>>> On Thu, 2016-08-11 at 22:45 -0700, Khem Raj wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Aug 11, 2016, at 7:06 AM, André Draszik <git at andred.net> wrote:
>>>>> 
>>>>> The libnl+musl combination has two issues at the moment:
>>>>> a) a public header file #include's an incorrect file
>>>>>   (sys/poll.h instead of poll.h), which causes warnings and
>>>>>   potentially errors (-Werror) in a musl based system
>>>>> b) musl only ever provides the XSI version of strerror_r()
>>>>> 
>>>> 
>>>> yes so you can check for something like
>>>> (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE
>>>> use XSI version
>>>> else use GNU version
>>> 
>>> Well, the feature test is supposed to be set by the user (libnl in this
>>> case), and evaluated by the c library (musl). libnl explicitly sets
>>> _GNU_SOURCE, i.e. it expects the glibc version.
>> 
>> I see. It is something which should atleast be brought up with
>> upstream as an issue
>> they may just say, we need GNU version but atleast we will know
> 
> It's actually quite a bad thing... There might be many users (you mentioned
> perf) out there which all are silently breaking because of this missing
> interface in musl. If you look at the patch, in the musl case the result was
> effectively a printf of an *int* with a *string format* specifier...
> 
> Maybe it'd be worth to convince musl to implement it (uclibc does), or at
> least to emit an #error?

Thinking more on this, there is an alternative to use strerror_l() rather
than strerror_r(), that will avoid the non-confirming versions issue, moreover
strerror_() is now recommended by posix to replace strerror_r() usage.

see

http://austingroupbugs.net/view.php?id=655

I think this is going to be a better solution since its portable.

> 
> I only noticed by coincidence...
> 
> 
> Cheers,
> Andre'
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160820/06d34462/attachment-0002.sig>