[oe] [meta-oe][PATCH] xterm: Fix latent issue found with musl

Khem Raj raj.khem at gmail.com
Sat Dec 14 05:55:49 UTC 2019


On 12/13/19 2:58 PM, Adrian Bunk wrote:
> On Fri, Dec 13, 2019 at 01:55:33PM -0800, Khem Raj wrote:
>> On Thu, Dec 12, 2019 at 8:37 PM Adrian Bunk <bunk at stusta.de> wrote:
>>> On Thu, Dec 12, 2019 at 12:22:52PM -0800, Khem Raj wrote:
>> ...
>>>> +_POSIX_SOURCE is app-defined not system
>>>
>>> This is true for musl, not for glibc.
>>>
>>> The handling of _POSIX_SOURCE and _POSIX_VERSION differs between musl
>>> and glibc due to glibc supporting older POSIX versions, and glibc also
>>> supporting developers of portable code to select some specific older
>>> POSIX version.
>>>
>> No thats not right.
>> _POSIX_SOURCE (like all FTMs) is
>> defined by the application to request a feature/standards profile
>> it's not libc telling you "this is posix" or anything like that.
> 
> It is also defined when _POSIX_C_SOURCE is defined, or _GNU_SOURCE,
> or when the default non-strict gcc mode is used.
> 
> The latter means that it is in practice nearly always defined when the
> libc supports applications written against older versions of POSIX.
> 
but these macros are not used in this case so its irrelevant here.

>> _POSIX_VERSION tells you that
>> ...
> 
> _POSIX_VERSION being defined tells you that you have unistd.h included.
> 
> With glibc the value of _POSIX_VERSION depends on what feature/standards
> profile the application has requested.

I would not look into how glibc does something and call it standard. It 
guards these definitions by its internal defines ( prefixed with __) 
which is internal to a libc implementation, applications are not exposed 
to private namespace.


> 
> cu
> Adrian
> 



More information about the Openembedded-devel mailing list