On Wed, May 04, 2011 at 03:38:28PM +0100, Måns Rullgård wrote: > Luca Barbato <lu_z...@gentoo.org> 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<di...@biurrun.de> writes: > >>> > >>>> On Wed, May 04, 2011 at 11:23:16AM +0100, Måns Rullgård wrote: > >>>>> Diego Biurrun<di...@biurrun.de> writes: > >>>>> > >>>>>> On Wed, May 04, 2011 at 10:23:17AM +0100, Måns Rullgård wrote: > >>>>>>> Diego Biurrun<di...@biurrun.de> 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.
lockf has the most hits, so I went for lockf - please test on your obscure machines.. Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
