On Thu, Sep 04, 2014 at 11:27:49PM +0200, Jörg Krause wrote: > > On 09/04/2014 05:27 PM, Hendrik Leppkes wrote: > >On Wed, Sep 3, 2014 at 11:53 AM, Jörg Krause <jkra...@posteo.de> 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(). > >> > >>[..] > > _XOPEN_SOURCE 600 is set as a compiler parameter for all other > >toolchains that need it, including glibc and whatnot. > >We should really do the same for musl here, using special treatment is weird. > > > >Detect musl in configure, add a new libc block, set > >-D_XOPEN_SOURCE=600 in the cflags, and it would be consistent with > >everything else. > > We had a discussion about this issue here at the mailing list. > > Detecting musl in configure is not possible. There is no __MUSL__ like > __GLIBC__ in <features.h>. The maintainers of musl prefer that the library > is tested for the exposed feature set. > > Another approach is to set the desired feature test macro at source level, > which is the recommation of the GNU C Library Reference Manual, instead of > setting it with -D. > > If we follow this approach, we have constintency for glibc, uclibc, and > musl. And we do not need a libc block for them in configure (at least not > for setting any feature test macro with -D).
This argument doesn't make any sense to me. You would get the same effect by setting it with -D in configure unconditionally, and without having to manually add the define in every single file (if you add it only to some, you end up with a random set of enable features in each file, making quite a maintenance mess). The only problem with that approach is that there are some libraries where e.g. setting ISO_C_SOURCE means all BSD feature are disabled and impossible to enable, so we need special cases for these. But again, it's still only a question of making special cases in the files (and thus duplicating it all over), or doing it in configure. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
