Date: Fri, 12 Sep 2014 11:37:32 -0400 From: Rich Felker <dalias@...c.org> To: Jörg Krause <jkrause@...teo.de> Cc: musl@...ts.openwall.com Subject: Re: why is there no __MUSL__ macro? On Fri, Sep 12, 2014 at 09:35:22AM +0200, Jörg Krause wrote: > > On 09/11/2014 04:47 PM, Natanael Copa wrote: > >On Thu, 11 Sep 2014 13:00:09 +0200 > >Jörg Krause <jkrause@...teo.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. It might work to add -D_DEFAULT_SOURCE (note: not available until recent musl git) or -D_BSD_SOURCE to the global CFLAGS. What's happening, I think, is that because -std=c99 or similar is in the CFLAGS, default feature profile is getting suppressed, and _GNU_SOURCE is the only thing bringing back the usual features (in addition to lots of _GNU_SOURCE-only stuff, and strerror_r breakage). Having at least one more feature test macro defined globally would prevent this. Note also that modern glibc supports _DEFAULT_SOURCE, with the same semantics as musl: keeping the default stuff exposed even when a -std=* option would otherwise suppress it. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.