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. >> I also want to test this on some other obscure systems where I ran into >> similar conflicts. > > Once we have settled on the proper check implementation that would be > very much appreciated. And I get reason to fire up my IRIX and Tru64 machines. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
