Re: why is there no __MUSL__ macro?

["Jörg Krause" <jkrause@posteo.de>]

On 09/11/2014 04:47 PM, Natanael Copa wrote:
> On Thu, 11 Sep 2014 13:00:09 +0200
> Jörg Krause <jkrause@posteo.de> wrote:
>
>> Hi,
>>
>> I am trying to add support for the musl toolchain to FFmpeg.
>>
>> FFmpeg needs support for library features defined in POSIX.1-2001 with
>> XSI extension and the standards below. Currently configure probes the
>> host and target libc by checking for defined macros like __GLIBC__ and
>> __UCLIBC__. In case of glibc and uclibc it sets -D_XOPEN_SOURCE=600
>> properly.
>>
>> After this it checks for some combinations of hardware and the probed
>> libc to set some more compile options, if necessary.
>>
>> I know that musl does not have a macro __MUSL__ and I have read the
>> explanation. However, I don't understand what's meant by "[..] it's a
>> bug to assume a certain implementation has particular properties rather
>> than testing." and how does it affect the way FFmpeg probes for the libc.
>>
>> What could be a solution which supports musl?
>>
>> Many thanks!
>> Jörg
> This is what we do on alpine linux:
> http://git.alpinelinux.org/cgit/aports/tree/main/ffmpeg/fix-defines.patch
>
> --- ffmpeg-1.2.2.orig/libavutil/error.c
> +++ ffmpeg-1.2.2/libavutil/error.c
> @@ -17,6 +17,7 @@
>    */
>   
>   #undef _GNU_SOURCE
> +#define _XOPEN_SOURCE 600
>   #include "avutil.h"
>   #include "avstring.h"
>   #include "common.h"
>

Hi Natanal,

I had a look to alpine already. I submitted this patch to FFmpeg, but 
building FFmpeg with my configuration libavutils/error.c is not the only 
file which needs a feature test macro. The people of FFmpeg did not like 
the idea to have a lot of test macros in there source so I stopped with 
this solution and looked for a way to adopt the musl toolchain to their 
configure file.