Luca Barbato <[email protected]> writes: > On 5/4/11 2:50 PM, Diego Biurrun wrote: >> On Wed, May 04, 2011 at 12:04:09PM +0100, Måns Rullgård wrote: >>> Diego Biurrun<[email protected]> writes: >>> >>>> 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. >>>>>>>> >>>>>>>> --- a/configure >>>>>>>> +++ b/configure >>>>>>>> @@ -2310,7 +2310,9 @@ if test "$?" != 0; then >>>>>>>> >>>>>>>> -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? >>> >>> Do a google code search: http://www.google.com/codesearch >> >> This is practically useless since it does not allow regular expressions. >> I get matches for unix_lockf, lockfile_foo and lockfile_bar and about >> a trillion hits for stuff with sync in the name. > > [^:alpha:]sync*[^:alpha:]\( lang:c > > seems working fine (even if I'm not sure I used the most correct syntax)
function:^sync$ does the trick too. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
