On Wed, May 04, 2011 at 11:23:16AM +0100, Måns Rullgård wrote: > Diego Biurrun <[email protected]> writes: > > > On Wed, May 04, 2011 at 10:23:17AM +0100, Måns Rullgård wrote: > >> Diego Biurrun <[email protected]> writes: > >> > >> > On some (BSD) systems _POSIX_C_SOURCE masks function definitions in > >> > system header files. Avoid the #define in that case. > >> > This allows eliminating some BSD-specific hacks. > >> > --- > >> > configure | 4 +++- > >> > doc/general.texi | 8 -------- > >> > 2 files changed, 3 insertions(+), 9 deletions(-) > >> > > >> > diff --git a/configure b/configure > >> > index 2b5aeab..51ec963 100755 > >> > --- a/configure > >> > +++ b/configure > >> > @@ -2310,7 +2310,9 @@ if test "$?" != 0; then > >> > die "C compiler test failed." > >> > fi > >> > > >> > -add_cppflags -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 > >> > +add_cppflags -D_ISOC99_SOURCE > >> > +check_func_headers unistd.h swab -D_POSIX_C_SOURCE=200112 && > >> > + add_cppflags -D_POSIX_C_SOURCE=200112 > >> > >> We need to be more careful here since this will omit the define on any > >> system lacking that function entirely. This could be any non-POSIX > >> system or a POSIX system without the X/Open extensions. Defining > >> _POSIX_C_SOURCE for non-POSIX systems is of course a bit odd. > > > > What about running a two-staged test then: Pick some function to test > > for and see if it is available without but not available with the > > POSIX flag set. If both of these conditions trigger, skip adding > > the POSIX flag to our CPPFLAGS. > > That's what I was thinking. Perhaps something slightly less obscure > than swab() could be chosen though. Pick something with an XSI label > from http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html > gethostid, lockf, nice, or sync might be good choices.
None of these are actually used in Libav either. I don't see any better choice right now though. Do you have a suggestion which one of those four is the most common and thus least likely to be missing on some strange system? Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
