On Thu, Sep 18, 2014 at 8:24 PM, Jörg Krause <jkra...@posteo.de> wrote:
> > On 09/18/2014 07:10 PM, Reimar Döffinger wrote: > >> On 18.09.2014, at 17:26, Michael Niedermayer <michae...@gmx.at> wrote: >> >>> On Thu, Sep 18, 2014 at 04:22:27PM +0200, Jörg Krause wrote: >>> >>>> glibc, uclibc, and musl uses feature test macros to expose definitions >>>> conforming to the standards ISO C, POSIX and extensions. According to >>>> which feature test macros are defined by the user or the compiler, >>>> the header file <features.h> used by these libraries internally defines >>>> various other macros. >>>> >>>> glibc and uclibc also defines release test macros, eg __GLIBC__ and >>>> __UCLIBC__ in <features.h>. musl does not have (and do not want) such >>>> a macro like __MUSL__. >>>> >>>> Building ffmpeg with the musl toolchain needs the feature test macro >>>> _XOPEN_SOURCE=600 to be defined. As it is not possible to detect musl >>>> check for the <features.h> header file, which is assumed to be specific >>>> to glibc, uclibc, and musl. >>>> >>>> Signed-off-by: Jörg Krause <jkra...@posteo.de> >>>> --- >>>> Changes v1 -> v2: >>>> - do not set _XOPEN_SOURCE twice for glibc and uclibc >>>> >>> why do you not add the musl check at the end of the if/elif chain as >>> suggested ? >>> does that have some issue or problem ? >>> >>> now your patch removes POSIX_C_SOURCE=200112 for glibc & uclibc >>> maybe thats ok, maybe its not but it certainly doesnt belong in a >>> patch that adds musl support >>> If you think this change is desireable, please submit a seperate >>> patch >>> >> May I suggest to change configure to always add these (POSIX_C_SOURCE and >> _XOPEN_SOURCE) and we just remove them specifically for cases that cause >> issues? >> And this time _document_ why we even have these hacks. >> Because as it it's impossible to know if all those special case are there >> for a reason or if they only exist because it's fun and nicely obfuscates >> configure. >> > > LGTM. I also discussed with the people at the musl mailing list and this > was their opinion to. First define the default and then add the hacks. > > > libav has also been working on this particular issue, and they are just adding _DEFAULT_SOURCE to the defines if the specific libc is unknown. Would that work? - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel