GNU bug report logs - #9141
Coreutils Compiler Warnings on OSX 10.7 (Lion)

Previous Next

Full log

Message #47 received at 9141 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9141 <at> debbugs.gnu.org, Bug-gnulib <bug-gnulib <at> gnu.org>
Subject: Re: bug#9141: fdatasync module proposal
Date: Fri, 16 Sep 2011 12:28:28 -0600

On 07/22/2011 03:13 PM, Paul Eggert wrote:
> Surely coreutils is not the only program that will have problems
> with fdatasync on Mac OS.  How about the following gnulib patches?

>
>   Portability problems fixed by Gnulib:
>   @itemize
> +@item
> +This function is present but undeclared and ineffective on some platforms:
> +MacOS X 10.7

Do we know this to be the case, or are you just going off of web 
searches?  For example:

http://patchwork.ozlabs.org/patch/33954/

"Although the fdatasync function is not referenced in the standard 
includes (hence the warning), it is present as a syscall:
/usr/include/sys/syscall.h:#define	SYS_fdatasync      187
Moreover, a fdatasync symbol is available through libSystem"

"Compiling just fine doesn't necessarily mean thatt qemu will run fine 
and do what we want it to do.
But in this case it may: i took a look at the XNU sources (I didn't 
think about this solution first, I forgot it was open source...) and 
fdatasync appears to be implemented."

That is, on MacOS 10.7, must we implement fdatasync via the heavier 
fsync, or can we merely add the declaration and let the syscall do its job?

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.