On 09/02/2014 11:49 PM, Reimar Döffinger wrote:
On Tue, Sep 02, 2014 at 11:31:39PM +0200, Jörg Krause wrote:
The maintainers of the musl C library states that looking for __GLIBC__ or
__UCLIBC__ and making assumptions about the implemented feature set is not
the best way. Instead <features.h> should be inspected for the specification
of the feature test macros. Here are links to a discussion on the musl
mailing list:
I don't know for sure, but I suspect features.h won't help you one bit
for the things that configure check was supposed to solve, like the
fact that some specific POSIX compliance flag on some platforms will
hide a specific feature with no way to get it back again, yet you
need the POSIX features enabled by that flag.
Unless you propose to test all 100s of combinations of flags until
we find one that looks like it works, which I'd object to on the
reason that configure is already too slow.
If I check the defined feature test macros in <features.h> I get the
following results for the musl toolchain and the GNU C toolchain with glibc:
x86_64-linux-musl-gcc:
_XOPEN_SOURCE defined: 700
_BSD_SOURCE defined
gcc (glibc 2.19):
_POSIX_SOURCE defined
_POSIX_C_SOURCE defined: 200809L
_BSD_SOURCE defined
_SVID_SOURCE defined
_ATFILE_SOURCE defined
So configure can ascertain these values and set CPPFLAGS accordingly
without to distinguish which (POSIX compliant) C library is used. Maybe
the values will differ for different platforms but this is not a problem
for configure. Just take the values and pass them to the
preprocessor/compiler. Nothing else is done in the current configure,
except that configure ascertains the libc type and then assings the
feature test macros. E.g. if configure found glibc then it says you are
_POSIX_C_SOURCE=200112 and _XOPEN_SOURCE=600. Which is not even true for
the latter case as you can see above for my gcc.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
