[FFmpeg-devel] [PATCH v2 1/1] configure: Refactor setting of feature test macro _XOPEN_SOURCE

[Jörg Krause]

On 09/19/2014 01:05 PM, Hendrik Leppkes wrote:
> On Thu, Sep 18, 2014 at 8:24 PM, Jörg Krause <jkrause at posteo.de> wrote:
>
>> On 09/18/2014 07:10 PM, Reimar Döffinger wrote:
>>
>>> On 18.09.2014, at 17:26, Michael Niedermayer <michaelni at gmx.at> wrote:
>>>
>>>> On Thu, Sep 18, 2014 at 04:22:27PM +0200, Jörg Krause wrote:
>>>>
>>>>> glibc, uclibc, and musl uses feature test macros to expose definitions
>>>>> conforming to the standards ISO C, POSIX and extensions. According to
>>>>> which feature test macros are defined by the user or the compiler,
>>>>> the header file <features.h> used by these libraries internally defines
>>>>> various other macros.
>>>>>
>>>>> glibc and uclibc also defines release test macros, eg __GLIBC__ and
>>>>> __UCLIBC__ in <features.h>. musl does not have (and do not want) such
>>>>> a macro like __MUSL__.
>>>>>
>>>>> Building ffmpeg with the musl toolchain needs the feature test macro
>>>>> _XOPEN_SOURCE=600 to be defined. As it is not possible to detect musl
>>>>> check for the <features.h> header file, which is assumed to be specific
>>>>> to glibc, uclibc, and musl.
>>>>>
>>>>> Signed-off-by: Jörg Krause <jkrause at posteo.de>
>>>>> ---
>>>>> Changes  v1 -> v2:
>>>>>    - do not set _XOPEN_SOURCE twice for glibc and uclibc
>>>>>
>>>> why do you not add the musl check at the end of the if/elif chain as
>>>> suggested ?
>>>> does that have some issue or problem ?
>>>>
>>>> now your patch removes POSIX_C_SOURCE=200112 for glibc & uclibc
>>>> maybe thats ok, maybe its not but it certainly doesnt belong in a
>>>> patch that adds musl support
>>>> If you think this change is desireable, please submit a seperate
>>>> patch
>>>>
>>> May I suggest to change configure to always add these (POSIX_C_SOURCE and
>>> _XOPEN_SOURCE) and we just remove them specifically for cases that cause
>>> issues?
>>> And this time _document_ why we even have these hacks.
>>> Because as it it's impossible to know if all those special case are there
>>> for a reason or if they only exist because it's fun and nicely obfuscates
>>> configure.
>>>
>> LGTM. I also discussed with the people at the musl mailing list and this
>> was their opinion to. First define the default and then add the hacks.
>>
>>
>>
> libav has also been working on this particular issue, and they are just
> adding _DEFAULT_SOURCE to the defines if the specific libc is unknown.
> Would that work?

It depends on the default settings of the C library. AFAIK the macro is 
not yet implemented in the current musl release.