[FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain

[Jörg Krause]

On 09/02/2014 07:41 PM, Reimar Döffinger wrote:
> On Tue, Sep 02, 2014 at 05:03:56PM +0200, Michael Niedermayer wrote:
>> On Tue, Sep 02, 2014 at 01:52:24PM +0200, Jörg Krause wrote:
>>>
>>> Am 02.09.2014 12:40 schrieb Michael Niedermayer:
>>>> On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote:
>>>>> Add the feature test macro which is required for building with the
>>>>> musl toolchain.
>>>>>
>>>>> The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant
>>>>> version of strerror_r().
>>>> is there a reason why you dont set it from configure ?
>>>> similar to the existing "-D_XOPEN_SOURCE=600" code in configure ?
>>>>
>>>> [...]
>>> I followed the recommendation from the GNU C Library Reference
>>> Manual, ch. 1.3.4 Feature Test Macro:
>>>
>>> You should define these macros by using ‘#define’ preprocessor
>>> directives at the top of your source code files. These directives
>>> must come before any #include of a system header file. It is best to
>>> make them the very first thing in the file, preceded only by
>>> comments. You could also use the ‘-D’ option to GCC, but it's better
>>> if you make the source files indicate their own meaning in a
>>> self-contained way.
>>>
>>> Do you prefer to define the macro in configure?
>> i prefer that all libcs are handled the same way
> And to be honest the configure check seems backwards to me, why isn't
> -D_XOPEN_SOURCE=600 used by default?
> Do all of klibc, bionic, mingw32, mingw64, cygwin/newlib, msvcrt break
> if you add it?

There are two possibilities for the usage of the feature test macros:

 1. at source level
 2. via -D options passed as arguments to the preprocessor or compiler

FFmpeg use both of them: Defining via -D in configure and undefine at 
source level (e.g. #undef _GNU_SOURCE). As written before the GNU C 
Library Reference Manual suggests the usage at the source level.

The maintainers of the musl C library states that looking for __GLIBC__ 
or __UCLIBC__ and making assumptions about the implemented feature set 
is not the best way. Instead <features.h> should be inspected for the 
specification of the feature test macros. Here are links to a discussion 
on the musl mailing list:
http://www.openwall.com/lists/musl/2013/03/29/13
http://www.openwall.com/lists/musl/2013/03/30/2 + 
http://www.openwall.com/lists/musl/2013/03/30/4

So we should decide which possibility we prefer for FFmpeg. If we do set 
the macros at source level we do not need to set them in configure (in 
case of a GNU C compliant library). If we want to set them in configure 
we can inspect <features.h> and ascertain the effects of the features 
test macros.

What do you think?