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

[Jörg Krause]

On 09/02/2014 11:49 PM, Reimar Döffinger wrote:
> On Tue, Sep 02, 2014 at 11:31:39PM +0200, Jörg Krause wrote:
>> 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:
> I don't know for sure, but I suspect features.h won't help you one bit
> for the things that configure check was supposed to solve, like the
> fact that some specific POSIX compliance flag on some platforms will
> hide a specific feature with no way to get it back again, yet you
> need the POSIX features enabled by that flag.
> Unless you propose to test all 100s of combinations of flags until
> we find one that looks like it works, which I'd object to on the
> reason that configure is already too slow.

If I check the defined feature test macros in <features.h> I get the 
following results for the musl toolchain and the GNU C toolchain with glibc:

x86_64-linux-musl-gcc:

    _XOPEN_SOURCE defined: 700
    _BSD_SOURCE defined

gcc (glibc 2.19):

    _POSIX_SOURCE defined
    _POSIX_C_SOURCE defined: 200809L
    _BSD_SOURCE defined
    _SVID_SOURCE defined
    _ATFILE_SOURCE defined

So configure can ascertain these values and set CPPFLAGS accordingly 
without to distinguish which (POSIX compliant) C library is used. Maybe 
the values will differ for different platforms but this is not a problem 
for configure. Just take the values and pass them to the 
preprocessor/compiler. Nothing else is done in the current configure, 
except that configure ascertains the libc type and then assings the 
feature test macros. E.g. if configure found glibc then it says you are 
_POSIX_C_SOURCE=200112 and _XOPEN_SOURCE=600. Which is not even true for 
the latter case as you can see above for my gcc.