Re: why is there no __MUSL__ macro?

[Jens <jensl@jelaas.eu>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1860 bytes --]


On Thu, 11 Sep 2014, Jörg Krause 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.

Maybe the explanation in the FAQ could be a bit more verbose.
But if you stop and think for a bit you'll realize that __MUSL__ would 
tell you next to nothing. musl and any other libc that is maintained will 
change with time. You cannot assume a specific functionality by checking 
for __MUSL__. Bugs will be fixed, functionality will be implemented etc.

Even if you could check for a specific version of musl you will do most 
people a disservice since their libc/version wont be handled.

If instead you check for a specific functionality, it will be independent 
of libc and version of libc.

A somewhat limited build of ffmpeg, atleast, works fine with musl:
OPTPREFIX=opt/av
configure --prefix=/$OPTPREFIX \
  --enable-gpl\
  --enable-small --disable-ffplay --disable-ffprobe --disable-ffserver\
  --enable-libmp3lame\
  --enable-libx264 \
  --disable-network --cc=musl-gcc

Thats my understanding, for what its worth.

Regards,
Jens

> 
> What could be a solution which supports musl?
> 
> Many thanks!
> Jörg
> 
>