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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9141 in the body.
You can then email your comments to 9141 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Herb Wartens <hawartens <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Coreutils Compiler Warnings on OSX 10.7 (Lion)
Date: Thu, 21 Jul 2011 02:16:32 -0700

[Message part 1 (text/plain, inline)]

OSX does have fdatasync defined as part of the libsystem_kernel.dylib library.  The problem is that there is no header on OSX that actually provides the function.  

There is another issue where I redefined PRIuMAX to "llu" and PRIdMAX to "lld" on OSX.  This was necessary because the build was picking up the lib/stdint.h provided with coreutils.  In there we ended up defining uintmax_t as a uint64_t.

<snip>
#elif defined GL_UINT64_T
# define uintmax_t uint64_t
#else
</snip>

However by default on OSX, PRIdMAX is defined as "jd" and PRIuMAX is defined as "ju."

I have added a hack to get coreutils to compile cleanly on OSX.  Hope this helps.

-Herb

[coreutils_warnings.diff (application/octet-stream, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Herb Wartens <hawartens <at> gmail.com>
Cc: 9141 <at> debbugs.gnu.org, Bug-gnulib <bug-gnulib <at> gnu.org>
Subject: Re: bug#9141: Coreutils Compiler Warnings on OSX 10.7 (Lion)
Date: Thu, 21 Jul 2011 14:53:25 -0700

[Adding bug-gnulib; the original bug report is <http://debbugs.gnu.org/9141>.]

On 07/21/11 02:16, Herb Wartens wrote:

> I have added a hack to get coreutils to compile cleanly on OSX.

Thanks, but we should fix this problem more cleanly.  Does the
following patch to lib/stdint.in.h solve your problem?  This fix is
already scheduled to appear in the next version of coreutils.  If it
doesn't solve your problem, what are the symptoms of failure?

--- old/lib/stdint.in.h	2011-03-13 04:32:31.000000000 -0700
+++ new/lib/stdint.in.h	2011-07-21 14:47:33.901160610 -0700
@@ -272,6 +272,12 @@ typedef unsigned long int gl_uintptr_t;
 /* Note: These types are compiler dependent. It may be unwise to use them in
    public header files. */
 
+/* If the system defines INTMAX_MAX, assume that intmax_t works, and
+   similarly for UINTMAX_MAX and uintmax_t.  This avoids problems with
+   assuming one type where another is used by the system.  */
+
+#ifndef INTMAX_MAX
+# undef INTMAX_C
 #undef intmax_t
 #if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1
 typedef long long int gl_intmax_t;
@@ -282,7 +288,10 @@ typedef long long int gl_intmax_t;
 typedef long int gl_intmax_t;
 # define intmax_t gl_intmax_t
 #endif
+#endif
 
+#ifndef UINTMAX_MAX
+# undef UINTMAX_C
 #undef uintmax_t
 #if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1
 typedef unsigned long long int gl_uintmax_t;
@@ -293,6 +302,7 @@ typedef unsigned long long int gl_uintma
 typedef unsigned long int gl_uintmax_t;
 # define uintmax_t gl_uintmax_t
 #endif
+#endif
 
 /* Verify that intmax_t and uintmax_t have the same size.  Too much code
    breaks if this is not the case.  If this check fails, the reason is likely
@@ -433,8 +443,8 @@ typedef int _verify_intmax_size[sizeof (
 
 /* 7.18.2.5. Limits of greatest-width integer types */
 
+#ifndef INTMAX_MAX
 #undef INTMAX_MIN
-#undef INTMAX_MAX
 #ifdef INT64_MAX
 # define INTMAX_MIN  INT64_MIN
 # define INTMAX_MAX  INT64_MAX
@@ -442,13 +452,15 @@ typedef int _verify_intmax_size[sizeof (
 # define INTMAX_MIN  INT32_MIN
 # define INTMAX_MAX  INT32_MAX
 #endif
+#endif
 
-#undef UINTMAX_MAX
+#ifndef UINTMAX_MAX
 #ifdef UINT64_MAX
 # define UINTMAX_MAX  UINT64_MAX
 #else
 # define UINTMAX_MAX  UINT32_MAX
 #endif
+#endif
 
 /* 7.18.3. Limits of other integer types */
 
@@ -570,7 +582,7 @@ typedef int _verify_intmax_size[sizeof (
 
 /* 7.18.4.2. Macros for greatest-width integer constants */
 
-#undef INTMAX_C
+#ifndef INTMAX_C
 #if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1
 # define INTMAX_C(x)   x##LL
 #elif defined GL_INT64_T
@@ -578,8 +590,9 @@ typedef int _verify_intmax_size[sizeof (
 #else
 # define INTMAX_C(x)   x##L
 #endif
+#endif
 
-#undef UINTMAX_C
+#ifndef UINTMAX_C
 #if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1
 # define UINTMAX_C(x)  x##ULL
 #elif defined GL_UINT64_T
@@ -587,6 +600,7 @@ typedef int _verify_intmax_size[sizeof (
 #else
 # define UINTMAX_C(x)  x##UL
 #endif
+#endif
 
 #endif /* !defined __cplusplus || defined __STDC_CONSTANT_MACROS */
 

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Herb Wartens <hawartens <at> gmail.com>
Cc: 9141 <at> debbugs.gnu.org, Bug-gnulib <bug-gnulib <at> gnu.org>
Subject: Re: bug#9141: Coreutils Compiler Warnings on OSX 10.7 (Lion)
Date: Thu, 21 Jul 2011 15:08:14 -0700

On 07/21/11 02:16, Herb Wartens wrote:
> OSX does have fdatasync defined as part of the libsystem_kernel.dylib library.
> The problem is that there is no header on OSX that actually provides the function.

Thanks again for reporting this.

What is the exact symptom of failure here?
If 'configure' successfully linked to fdatasync, then
presumably coreutils can link to it too.  So presumably
your compiler complained about the missing declaration.
But did it go ahead and use fdatasync anyway?  If so,
we're done: you can just ignore the diagnostic.  If not,
perhaps 'configure' should check that fdatasync is declared
(and not just linkable too), and use fdatasync only if it
is declared; that would be more-conservative.

Have you checked, via "grep -r fdatasync /usr/include/", whether
fdatasync is actually present anywhere?  It might be declared only
if some other symbol is #define'd, in which case, we should find
out what that is and #define it.

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

From: Herb Wartens <hawartens <at> gmail.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: Coreutils Compiler Warnings on OSX 10.7 (Lion)
Date: Thu, 21 Jul 2011 16:00:27 -0700

[Message part 1 (text/plain, inline)]

On 07/21/11 02:16, Herb Wartens wrote:
>
> > I have added a hack to get coreutils to compile cleanly on OSX.
>
> Thanks, but we should fix this problem more cleanly.  Does the
> following patch to lib/stdint.in.h solve your problem?  This fix is
> already scheduled to appear in the next version of coreutils.  If it
> doesn't solve your problem, what are the symptoms of failure?
>
>
I agree.  Fixing it more cleanly would definitely be better!  The patch I
sent was a hack just to get coreutils compiling cleanly.  The patch you sent
does indeed remove the compiler warnings I was seeing when printing integers
with the PRIuMAX and PRIdMAX macros on OSX. I am still seeing the fdatasync
warnings though.

[Message part 2 (text/html, inline)]

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

From: Herb Wartens <hawartens <at> gmail.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: Coreutils Compiler Warnings on OSX 10.7 (Lion)
Date: Thu, 21 Jul 2011 16:08:13 -0700

[Message part 1 (text/plain, inline)]

On Thu, Jul 21, 2011 at 3:08 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 07/21/11 02:16, Herb Wartens wrote:
> > OSX does have fdatasync defined as part of the libsystem_kernel.dylib
> library.
> > The problem is that there is no header on OSX that actually provides the
> function.
>
> Thanks again for reporting this.
>
>
No problem.



> What is the exact symptom of failure here?
> If 'configure' successfully linked to fdatasync, then
> presumably coreutils can link to it too.  So presumably
> your compiler complained about the missing declaration.
> But did it go ahead and use fdatasync anyway?  If so,
> we're done: you can just ignore the diagnostic.  If not,
>


I prefer to have my code always compile cleanly.  I have found that when
compiling code that generates a lot of warnings, people tend to ignore them
(even important ones).  The linker was able to resolve the fdatasync and
include it in the binaries:

# nm /usr/local/apps/Utils/coreutils/bin/dd | grep fdatasync
                 U _fdatasync

# otool -L /usr/local/apps/Utils/coreutils/bin/dd
/usr/local/apps/Utils/coreutils/bin/dd:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
159.0.0)

# otool -L /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib:
<snip>
/usr/lib/system/libsystem_kernel.dylib (compatibility version 1.0.0, current
version 1699.22.73)
 </snip>

# nm /usr/lib/system/libsystem_kernel.dylib | grep fdatasync
0000000000017430 T _fdatasync



> perhaps 'configure' should check that fdatasync is declared
> (and not just linkable too), and use fdatasync only if it
> is declared; that would be more-conservative.
>
>
It would be more conservative, but we really could use it since we have it
defined in a library.  Unfortunately Apple did not include a header to
define it properly.  It's your call though as I would think either way is
fine (though some may prefer to actually have the fdatasync functionality).



> Have you checked, via "grep -r fdatasync /usr/include/", whether
> fdatasync is actually present anywhere?  It might be declared only
> if some other symbol is #define'd, in which case, we should find
> out what that is and #define it.
>


Yes I have checked, but I will leave you the results so that you
candouble-check me...=)
> grep -R fdatasync /usr/include
/usr/include/pg_config.h:/* Define to 1 if you have the declaration of
`fdatasync', and to 0 if you
/usr/include/pg_config.h:/* Define to 1 if you have the `fdatasync'
function. */
/usr/include/postgresql/internal/c.h:extern int fdatasync(int fildes);
/usr/include/postgresql/server/access/xlogdefs.h: * configure determined
whether fdatasync() is.
/usr/include/postgresql/server/c.h:extern int fdatasync(int fildes);
/usr/include/postgresql/server/pg_config.h:/* Define to 1 if you have the
declaration of `fdatasync', and to 0 if you
/usr/include/postgresql/server/pg_config.h:/* Define to 1 if you have the
`fdatasync' function. */
/usr/include/postgresql/server/port/linux.h: * Set the default
wal_sync_method to fdatasync.  With recent Linux versions,
/usr/include/postgresql/server/storage/fd.h:extern int pg_fdatasync(int fd);
/usr/include/python2.5/pyconfig.h:/* Define if you have the 'fdatasync'
function. */
/usr/include/python2.5/pyport.h:extern int fdatasync(int);
/usr/include/python2.6/pyconfig.h:/* Define if you have the 'fdatasync'
function. */
/usr/include/python2.6/pyport.h:extern int fdatasync(int);
/usr/include/python2.7/pyconfig.h:/* Define if you have the 'fdatasync'
function. */
/usr/include/python2.7/pyport.h:extern int fdatasync(int);
/usr/include/sys/syscall.h:#define SYS_fdatasync      187

[Message part 2 (text/html, inline)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bug-gnulib <bug-gnulib <at> gnu.org>
Cc: 9141 <at> debbugs.gnu.org
Subject: [PATCH 1/3] extensions: Enable extensions on MacOS X 10.5 and later.
Date: Fri, 22 Jul 2011 10:18:12 -0700

Recent versions of MacOS seem to have a _DARWIN_C_SOURCE flag that
has roughly the same role that _GNU_SOURCE has for GNU systems.
I pushed the following patch into gnulib, under the theory that it is
more in the line with the usual Autoconf / gnulib philosophy,
and it may fix some porting issues.

Herb, can you please try configuring coreutils with this change?
If you don't have all the autotools installed, you can simply append
"#define _DARWIN_C_SOURCE 1" to lib/config.h after running "configure".
Thanks.

* m4/extensions.m4 (AC_USE_SYSTEM_EXTENSIONS): Define _DARWIN_C_SOURCE.
---
 ChangeLog        |    5 +++++
 m4/extensions.m4 |    7 ++++++-
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b22ea11..46d8d04 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2011-07-22  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	extensions: Enable extensions on MacOS X 10.5 and later.
+	* m4/extensions.m4 (AC_USE_SYSTEM_EXTENSIONS): Define _DARWIN_C_SOURCE.
+
 2011-07-22  Kamil Dudka  <kdudka <at> redhat.com>
 
 	file-has-acl: use acl_extended_file_nofollow if available
diff --git a/m4/extensions.m4 b/m4/extensions.m4
index 1330503..22156e0 100644
--- a/m4/extensions.m4
+++ b/m4/extensions.m4
@@ -1,4 +1,4 @@
-# serial 9  -*- Autoconf -*-
+# serial 10  -*- Autoconf -*-
 # Enable extensions on systems that normally disable them.
 
 # Copyright (C) 2003, 2006-2011 Free Software Foundation, Inc.
@@ -67,6 +67,10 @@ AC_BEFORE([$0], [AC_RUN_IFELSE])dnl
 #ifndef _ALL_SOURCE
 # undef _ALL_SOURCE
 #endif
+/* Enable general extensions on MacOS X.  */
+#ifndef _DARWIN_C_SOURCE
+# undef _DARWIN_C_SOURCE
+#endif
 /* Enable GNU extensions on systems that have them.  */
 #ifndef _GNU_SOURCE
 # undef _GNU_SOURCE
@@ -95,6 +99,7 @@ AC_BEFORE([$0], [AC_RUN_IFELSE])dnl
   test $ac_cv_safe_to_define___extensions__ = yes &&
     AC_DEFINE([__EXTENSIONS__])
   AC_DEFINE([_ALL_SOURCE])
+  AC_DEFINE([_DARWIN_C_SOURCE])
   AC_DEFINE([_GNU_SOURCE])
   AC_DEFINE([_POSIX_PTHREAD_SEMANTICS])
   AC_DEFINE([_TANDEM_SOURCE])
-- 
1.7.4.4

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Herb Wartens <hawartens <at> gmail.com>
Cc: 9141 <at> debbugs.gnu.org, Bug-gnulib <bug-gnulib <at> gnu.org>
Subject: Re: bug#9141: Coreutils Compiler Warnings on OSX 10.7 (Lion)
Date: Fri, 22 Jul 2011 13:47:18 -0700

On 07/21/11 16:00, Herb Wartens wrote:
> I am still seeing the fdatasync
> warnings though.

I just pushed this patch, which should fix things.
Please let me know if it doesn't.  Looking around the net,
it appears that the fdatasync of Mac OS 10.7 is not effective,
so it's better to be safe here and act as if it doesn't exist.


From 339613b6bdd8d4a51435cba9e903b8b5bb082da4 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Fri, 22 Jul 2011 13:40:03 -0700
Subject: [PATCH] dd, shred: use fdatasync only if declared

* m4/jm-macros.m4 (coreutils_MACROS): Use fdatasync only if declared.
MacOS X 10.7 has an fdatasync that is not declared, and is rumored to
be ineffective.  (Bug#9141)
---
 m4/jm-macros.m4 |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4
index 6e97221..58b000d 100644
--- a/m4/jm-macros.m4
+++ b/m4/jm-macros.m4
@@ -93,14 +93,20 @@ AC_DEFUN([coreutils_MACROS],
   cu_PREREQ_STAT_PROG
 
   # for dd.c and shred.c
-  coreutils_saved_libs=$LIBS
-    LIB_FDATASYNC=
+  #
+  # Use fdatasync only if declared.  On MacOS X 10.7, fdatasync exists but
+  # is not declared, and is ineffective.
+  LIB_FDATASYNC=
+  AC_SUBST([LIB_FDATASYNC])
+  AC_CHECK_DECLS_ONCE([fdatasync])
+  if test $ac_cv_have_decl_fdatasync = yes; then
+    coreutils_saved_libs=$LIBS
     AC_SEARCH_LIBS([fdatasync], [rt posix4],
                    [test "$ac_cv_search_fdatasync" = "none required" ||
                     LIB_FDATASYNC=$ac_cv_search_fdatasync])
-    AC_SUBST([LIB_FDATASYNC])
     AC_CHECK_FUNCS([fdatasync])
-  LIBS=$coreutils_saved_libs
+    LIBS=$coreutils_saved_libs
+  fi
 
   # Check whether libcap is usable -- for ls --color support
   LIB_CAP=
-- 
1.7.4.4

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bug-gnulib <bug-gnulib <at> gnu.org>
Cc: 9141 <at> debbugs.gnu.org
Subject: fdatasync module proposal
Date: Fri, 22 Jul 2011 14:13:29 -0700

Surely coreutils is not the only program that will have problems
with fdatasync on Mac OS.  How about the following gnulib patches?
One is for fdatasync, the other for its tests.

From d5c4b4b9266db16c8477a94640290e0b662cee93 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Fri, 22 Jul 2011 14:00:22 -0700
Subject: [PATCH 1/2] fdatasync: New module

* MODULES.html.sh: Add it.
* doc/posix-functions/fdatasync.texi (fdatasync): Document it.
* lib/unistd.in.h (fdatasync): Arrange for replacement.
* m4/unistd_h.m4 (gl_UNISTD_H): Prepare for warn-on-use.
(gl_UNISTD_H_DEFAULTS): Define defaults for it.
* modules/unistd (unistd.h): Substitute for its vars.
* lib/fdatasync.c, m4/fdatasync.m4, modules/fdatasync: New files.
---
 ChangeLog                          |    9 +++++++++
 MODULES.html.sh                    |    1 +
 doc/posix-functions/fdatasync.texi |   11 +++++++----
 lib/fdatasync.c                    |   30 ++++++++++++++++++++++++++++++
 lib/unistd.in.h                    |   28 ++++++++++++++++++++++++++++
 m4/fdatasync.m4                    |   34 ++++++++++++++++++++++++++++++++++
 m4/unistd_h.m4                     |    6 +++++-
 modules/fdatasync                  |   32 ++++++++++++++++++++++++++++++++
 modules/unistd                     |    4 ++++
 9 files changed, 150 insertions(+), 5 deletions(-)
 create mode 100644 lib/fdatasync.c
 create mode 100644 m4/fdatasync.m4
 create mode 100644 modules/fdatasync

diff --git a/ChangeLog b/ChangeLog
index b652f25..15b0fe5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,14 @@
 2011-07-22  Paul Eggert  <eggert <at> cs.ucla.edu>
 
+	fdatasync: New module
+	* MODULES.html.sh: Add it.
+	* doc/posix-functions/fdatasync.texi (fdatasync): Document it.
+	* lib/unistd.in.h (fdatasync): Arrange for replacement.
+	* m4/unistd_h.m4 (gl_UNISTD_H): Prepare for warn-on-use.
+	(gl_UNISTD_H_DEFAULTS): Define defaults for it.
+	* modules/unistd (unistd.h): Substitute for its vars.
+	* lib/fdatasync.c, m4/fdatasync.m4, modules/fdatasync: New files.
+
 	fsusage: port to MacOS X 10.7 with 4 TiB file systems
 	* m4/fsusage.m4 (gl_FILE_SYSTEM_USAGE): Reject statvfs
 	implementations that use only 32 bits to count blocks.
diff --git a/MODULES.html.sh b/MODULES.html.sh
index 80befa9..a185c42 100755
--- a/MODULES.html.sh
+++ b/MODULES.html.sh
@@ -2360,6 +2360,7 @@ func_all_modules ()
   func_module fclose
   func_module fcntl-h
   func_module fcntl
+  func_module fdatasync
   func_module flock
   func_module fopen
   func_module fprintf-posix
diff --git a/doc/posix-functions/fdatasync.texi b/doc/posix-functions/fdatasync.texi
index 8631207..2c581d8 100644
--- a/doc/posix-functions/fdatasync.texi
+++ b/doc/posix-functions/fdatasync.texi
@@ -4,15 +4,18 @@
 
 POSIX specification:@* @url{http://www.opengroup.org/onlinepubs/9699919799/functions/fdatasync.html}
 
-Gnulib module: ---
+Gnulib module: fdatasync
 
 Portability problems fixed by Gnulib:
 @itemize
+@item
+This function is present but undeclared and ineffective on some platforms:
+MacOS X 10.7
+@item
+This function is missing on some platforms:
+MacOS X 10.5, FreeBSD 6.0, OpenBSD 3.8, IRIX 5.3, Solaris 2.4, mingw, Interix 3.5, BeOS.
 @end itemize
 
 Portability problems not fixed by Gnulib:
 @itemize
-@item
-This function is missing on some platforms:
-MacOS X 10.5, FreeBSD 6.0, OpenBSD 3.8, IRIX 5.3, Solaris 2.4, mingw, Interix 3.5, BeOS.
 @end itemize
diff --git a/lib/fdatasync.c b/lib/fdatasync.c
new file mode 100644
index 0000000..fbb7b5a
--- /dev/null
+++ b/lib/fdatasync.c
@@ -0,0 +1,30 @@
+/* Emulate fdatasync on platforms that lack it.
+
+   Copyright (C) 2011 Free Software Foundation, Inc.
+
+   This library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   This library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+/* written by Paul Eggert */
+
+#include <config.h>
+
+#include <unistd.h>
+
+int
+fdatasync (int fd)
+#undef fdatasync
+{
+  /* This isn't right, but it's the best we can do portably.  */
+  return fsync (fd);
+}
diff --git a/lib/unistd.in.h b/lib/unistd.in.h
index e612fb3..aac5bb2 100644
--- a/lib/unistd.in.h
+++ b/lib/unistd.in.h
@@ -483,6 +483,34 @@ _GL_WARN_ON_USE (fchownat, "fchownat is not portable - "
 #endif
 
 
+#if @GNULIB_FDATASYNC@
+/* Synchronize data changes to a file.
+   Return 0 if successful, otherwise -1 and errno set.
+   See POSIX:2001 specification
+   <http://www.opengroup.org/susv3xsh/fdatasync.html>.  */
+# if @REPLACE_FDATASYNC@
+#  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
+#   undef fdatasync
+#   define fdatasync rpl_fdatasync
+#  endif
+_GL_FUNCDECL_RPL (fdatasync, int, (int /* fd */));
+_GL_CXXALIAS_RPL (fdatasync, int, (int /* fd */));
+# else
+#  if !@HAVE_DECL_FDATASYNC@
+_GL_FUNCDECL_SYS (fdatasync, int, (int /* fd */));
+#  endif
+_GL_CXXALIAS_SYS (fdatasync, int, (int /* fd */));
+# endif
+_GL_CXXALIASWARN (fdatasync);
+#elif defined GNULIB_POSIXCHECK
+# undef fdatasync
+# if HAVE_RAW_DECL_FDATASYNC
+_GL_WARN_ON_USE (fdatasync, "fdatasync is unportable - "
+                 "use gnulib module fdatasync for portability");
+# endif
+#endif
+
+
 #if @GNULIB_FSYNC@
 /* Synchronize changes to a file.
    Return 0 if successful, otherwise -1 and errno set.
diff --git a/m4/fdatasync.m4 b/m4/fdatasync.m4
new file mode 100644
index 0000000..af17970
--- /dev/null
+++ b/m4/fdatasync.m4
@@ -0,0 +1,34 @@
+# fdatasync.m4
+dnl Copyright 2011 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+dnl written by Paul Eggert
+
+AC_DEFUN([gl_FUNC_FDATASYNC],
+[
+  AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
+
+  LIB_FDATASYNC=
+  AC_SUBST([LIB_FDATASYNC])
+
+  AC_CHECK_DECLS_ONCE([fdatasync])
+  if test $ac_cv_have_decl_fdatasync = no; then
+    HAVE_DECL_FDATASYNC=0
+
+    # If it isn't declared, replace it.  This is better for MacOS X 10.7,
+    # where it is not declared, exists, and is ineffective.
+    REPLACE_FDATASYNC=1
+  else
+    gl_saved_libs=$LIBS
+      AC_SEARCH_LIBS([fdatasync], [rt posix4],
+                     [test "$ac_cv_search_fdatasync" = "none required" ||
+                      LIB_FDATASYNC=$ac_cv_search_fdatasync])
+      AC_CHECK_FUNCS([fdatasync])
+    LIBS=$gl_saved_libs
+    if test $ac_cv_func_fdatasync = no; then
+      HAVE_FDATASYNC=0
+    fi
+  fi
+])
diff --git a/m4/unistd_h.m4 b/m4/unistd_h.m4
index fb6fe07..dc6b63e 100644
--- a/m4/unistd_h.m4
+++ b/m4/unistd_h.m4
@@ -34,7 +34,7 @@ AC_DEFUN([gl_UNISTD_H],
 # endif
 #endif
     ]], [chown dup2 dup3 environ euidaccess faccessat fchdir fchownat
-    fsync ftruncate getcwd getdomainname getdtablesize getgroups
+    fdatasync fsync ftruncate getcwd getdomainname getdtablesize getgroups
     gethostname getlogin getlogin_r getpagesize getusershell setusershell
     endusershell group_member lchown link linkat lseek pipe pipe2 pread pwrite
     readlink readlinkat rmdir sleep symlink symlinkat ttyname_r unlink unlinkat
@@ -61,6 +61,7 @@ AC_DEFUN([gl_UNISTD_H_DEFAULTS],
   GNULIB_FACCESSAT=0;            AC_SUBST([GNULIB_FACCESSAT])
   GNULIB_FCHDIR=0;               AC_SUBST([GNULIB_FCHDIR])
   GNULIB_FCHOWNAT=0;             AC_SUBST([GNULIB_FCHOWNAT])
+  GNULIB_FDATASYNC=0;            AC_SUBST([GNULIB_FDATASYNC])
   GNULIB_FSYNC=0;                AC_SUBST([GNULIB_FSYNC])
   GNULIB_FTRUNCATE=0;            AC_SUBST([GNULIB_FTRUNCATE])
   GNULIB_GETCWD=0;               AC_SUBST([GNULIB_GETCWD])
@@ -104,6 +105,7 @@ AC_DEFUN([gl_UNISTD_H_DEFAULTS],
   HAVE_FACCESSAT=1;       AC_SUBST([HAVE_FACCESSAT])
   HAVE_FCHDIR=1;          AC_SUBST([HAVE_FCHDIR])
   HAVE_FCHOWNAT=1;        AC_SUBST([HAVE_FCHOWNAT])
+  HAVE_FDATASYNC=1;       AC_SUBST([HAVE_FDATASYNC])
   HAVE_FSYNC=1;           AC_SUBST([HAVE_FSYNC])
   HAVE_FTRUNCATE=1;       AC_SUBST([HAVE_FTRUNCATE])
   HAVE_GETDTABLESIZE=1;   AC_SUBST([HAVE_GETDTABLESIZE])
@@ -128,6 +130,7 @@ AC_DEFUN([gl_UNISTD_H_DEFAULTS],
   HAVE_USLEEP=1;          AC_SUBST([HAVE_USLEEP])
   HAVE_DECL_ENVIRON=1;    AC_SUBST([HAVE_DECL_ENVIRON])
   HAVE_DECL_FCHDIR=1;     AC_SUBST([HAVE_DECL_FCHDIR])
+  HAVE_DECL_FDATASYNC=1;  AC_SUBST([HAVE_DECL_FDATASYNC])
   HAVE_DECL_GETDOMAINNAME=1; AC_SUBST([HAVE_DECL_GETDOMAINNAME])
   HAVE_DECL_GETLOGIN_R=1; AC_SUBST([HAVE_DECL_GETLOGIN_R])
   HAVE_DECL_GETPAGESIZE=1; AC_SUBST([HAVE_DECL_GETPAGESIZE])
@@ -140,6 +143,7 @@ AC_DEFUN([gl_UNISTD_H_DEFAULTS],
   REPLACE_DUP=0;          AC_SUBST([REPLACE_DUP])
   REPLACE_DUP2=0;         AC_SUBST([REPLACE_DUP2])
   REPLACE_FCHOWNAT=0;     AC_SUBST([REPLACE_FCHOWNAT])
+  REPLACE_FDATASYNC=0;    AC_SUBST([REPLACE_FDATASYNC])
   REPLACE_GETCWD=0;       AC_SUBST([REPLACE_GETCWD])
   REPLACE_GETDOMAINNAME=0; AC_SUBST([REPLACE_GETDOMAINNAME])
   REPLACE_GETLOGIN_R=0;   AC_SUBST([REPLACE_GETLOGIN_R])
diff --git a/modules/fdatasync b/modules/fdatasync
new file mode 100644
index 0000000..94980ec
--- /dev/null
+++ b/modules/fdatasync
@@ -0,0 +1,32 @@
+Description:
+Synchronize data writes to a file.
+
+Files:
+lib/fdatasync.c
+m4/fdatasync.m4
+
+Depends-on:
+extensions
+fsync           [test $HAVE_FDATASYNC = 0]
+unistd
+
+configure.ac:
+gl_FUNC_FDATASYNC
+if test $HAVE_FDATASYNC = 0; then
+  AC_LIBOBJ([fdatasync])
+fi
+gl_UNISTD_MODULE_INDICATOR([fdatasync])
+
+Makefile.am:
+
+Include:
+<unistd.h>
+
+Link:
+$(LIB_FDATASYNC)
+
+License:
+LGPLv2+
+
+Maintainer:
+Paul Eggert, Jim Meyering
diff --git a/modules/unistd b/modules/unistd
index 6c8ea1e..8361608 100644
--- a/modules/unistd
+++ b/modules/unistd
@@ -38,6 +38,7 @@ unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) $(ARG_NONNULL_H
 	      -e 's/@''GNULIB_FACCESSAT''@/$(GNULIB_FACCESSAT)/g' \
 	      -e 's/@''GNULIB_FCHDIR''@/$(GNULIB_FCHDIR)/g' \
 	      -e 's/@''GNULIB_FCHOWNAT''@/$(GNULIB_FCHOWNAT)/g' \
+	      -e 's/@''GNULIB_FDATASYNC''@/$(GNULIB_FDATASYNC)/g' \
 	      -e 's/@''GNULIB_FSYNC''@/$(GNULIB_FSYNC)/g' \
 	      -e 's/@''GNULIB_FTRUNCATE''@/$(GNULIB_FTRUNCATE)/g' \
 	      -e 's/@''GNULIB_GETCWD''@/$(GNULIB_GETCWD)/g' \
@@ -81,6 +82,7 @@ unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) $(ARG_NONNULL_H
 	      -e 's|@''HAVE_FACCESSAT''@|$(HAVE_FACCESSAT)|g' \
 	      -e 's|@''HAVE_FCHDIR''@|$(HAVE_FCHDIR)|g' \
 	      -e 's|@''HAVE_FCHOWNAT''@|$(HAVE_FCHOWNAT)|g' \
+	      -e 's|@''HAVE_FDATASYNC''@|$(HAVE_FDATASYNC)|g' \
 	      -e 's|@''HAVE_FSYNC''@|$(HAVE_FSYNC)|g' \
 	      -e 's|@''HAVE_FTRUNCATE''@|$(HAVE_FTRUNCATE)|g' \
 	      -e 's|@''HAVE_GETDTABLESIZE''@|$(HAVE_GETDTABLESIZE)|g' \
@@ -105,6 +107,7 @@ unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) $(ARG_NONNULL_H
 	      -e 's|@''HAVE_USLEEP''@|$(HAVE_USLEEP)|g' \
 	      -e 's|@''HAVE_DECL_ENVIRON''@|$(HAVE_DECL_ENVIRON)|g' \
 	      -e 's|@''HAVE_DECL_FCHDIR''@|$(HAVE_DECL_FCHDIR)|g' \
+	      -e 's|@''HAVE_DECL_FDATASYNC''@|$(HAVE_DECL_FDATASYNC)|g' \
 	      -e 's|@''HAVE_DECL_GETDOMAINNAME''@|$(HAVE_DECL_GETDOMAINNAME)|g' \
 	      -e 's|@''HAVE_DECL_GETLOGIN_R''@|$(HAVE_DECL_GETLOGIN_R)|g' \
 	      -e 's|@''HAVE_DECL_GETPAGESIZE''@|$(HAVE_DECL_GETPAGESIZE)|g' \
@@ -118,6 +121,7 @@ unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) $(ARG_NONNULL_H
 	      -e 's|@''REPLACE_DUP''@|$(REPLACE_DUP)|g' \
 	      -e 's|@''REPLACE_DUP2''@|$(REPLACE_DUP2)|g' \
 	      -e 's|@''REPLACE_FCHOWNAT''@|$(REPLACE_FCHOWNAT)|g' \
+	      -e 's|@''REPLACE_FDATASYNC''@|$(REPLACE_FDATASYNC)|g' \
 	      -e 's|@''REPLACE_GETCWD''@|$(REPLACE_GETCWD)|g' \
 	      -e 's|@''REPLACE_GETDOMAINNAME''@|$(REPLACE_GETDOMAINNAME)|g' \
 	      -e 's|@''REPLACE_GETLOGIN_R''@|$(REPLACE_GETLOGIN_R)|g' \
-- 
1.7.4.4


From 68da59ddad1456ff7ddc67a66ef605c3a8888da0 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Fri, 22 Jul 2011 14:02:55 -0700
Subject: [PATCH 2/2] fdatasync-tests: New module

* modules/fdatasync-tests, tests/test-fdatasync.c: New files.
* tests/test-fsync.c (FSYNC): New macro, to let us test fdatasync.
* tests/test-unistd-c++.cc: Add fdatasync test.
---
 ChangeLog                |    5 +++++
 modules/fdatasync-tests  |   13 +++++++++++++
 tests/test-fdatasync.c   |    2 ++
 tests/test-fsync.c       |   10 +++++++---
 tests/test-unistd-c++.cc |    4 ++++
 5 files changed, 31 insertions(+), 3 deletions(-)
 create mode 100644 modules/fdatasync-tests
 create mode 100644 tests/test-fdatasync.c

diff --git a/ChangeLog b/ChangeLog
index 15b0fe5..f089c68 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2011-07-22  Paul Eggert  <eggert <at> cs.ucla.edu>
 
+	fdatasync-tests: New module
+	* modules/fdatasync-tests, tests/test-fdatasync.c: New files.
+	* tests/test-fsync.c (FSYNC): New macro, to let us test fdatasync.
+	* tests/test-unistd-c++.cc: Add fdatasync test.
+
 	fdatasync: New module
 	* MODULES.html.sh: Add it.
 	* doc/posix-functions/fdatasync.texi (fdatasync): Document it.
diff --git a/modules/fdatasync-tests b/modules/fdatasync-tests
new file mode 100644
index 0000000..3862eda
--- /dev/null
+++ b/modules/fdatasync-tests
@@ -0,0 +1,13 @@
+Files:
+tests/test-fdatasync.c
+tests/test-fsync.c
+tests/signature.h
+tests/macros.h
+
+Depends-on:
+
+configure.ac:
+
+Makefile.am:
+TESTS += test-fdatasync
+check_PROGRAMS += test-fdatasync
diff --git a/tests/test-fdatasync.c b/tests/test-fdatasync.c
new file mode 100644
index 0000000..90964cc
--- /dev/null
+++ b/tests/test-fdatasync.c
@@ -0,0 +1,2 @@
+#define FSYNC fdatasync
+#include "test-fsync.c"
diff --git a/tests/test-fsync.c b/tests/test-fsync.c
index 2627d0c..6bac01c 100644
--- a/tests/test-fsync.c
+++ b/tests/test-fsync.c
@@ -18,8 +18,12 @@
 
 #include <unistd.h>
 
+#ifndef FSYNC
+# define FSYNC fsync
+#endif
+
 #include "signature.h"
-SIGNATURE_CHECK (fsync, int, (int));
+SIGNATURE_CHECK (FSYNC, int, (int));
 
 #include <errno.h>
 #include <fcntl.h>
@@ -32,7 +36,7 @@ main (void)
   int fd;
   const char *file = "test-fsync.txt";
 
-  if (fsync (0) != 0)
+  if (FSYNC (0) != 0)
     {
       ASSERT (errno == EINVAL /* POSIX */
               || errno == ENOTSUP /* seen on MacOS X 10.5 */
@@ -42,7 +46,7 @@ main (void)
   fd = open (file, O_WRONLY|O_CREAT|O_TRUNC, 0644);
   ASSERT (0 <= fd);
   ASSERT (write (fd, "hello", 5) == 5);
-  ASSERT (fsync (fd) == 0);
+  ASSERT (FSYNC (fd) == 0);
   ASSERT (close (fd) == 0);
   ASSERT (unlink (file) == 0);
 
diff --git a/tests/test-unistd-c++.cc b/tests/test-unistd-c++.cc
index 12e415b..fb7425b 100644
--- a/tests/test-unistd-c++.cc
+++ b/tests/test-unistd-c++.cc
@@ -60,6 +60,10 @@ SIGNATURE_CHECK (GNULIB_NAMESPACE::fchownat, int,
                  (int, char const *, uid_t, gid_t, int));
 #endif
 
+#if GNULIB_TEST_FDATASYNC
+SIGNATURE_CHECK (GNULIB_NAMESPACE::fdatasync, int, (int));
+#endif
+
 #if GNULIB_TEST_FSYNC
 SIGNATURE_CHECK (GNULIB_NAMESPACE::fsync, int, (int));
 #endif
-- 
1.7.4.4

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

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org
Cc: 9141 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: [PATCH 1/3] extensions: Enable extensions on MacOS X 10.5 and
	later.
Date: Sat, 23 Jul 2011 02:23:47 +0200

Paul Eggert wrote:
> Recent versions of MacOS seem to have a _DARWIN_C_SOURCE flag that
> has roughly the same role that _GNU_SOURCE has for GNU systems.

It's not "roughly the same". _GNU_SOURCE makes some symbols visible that are
not visible by default. Whereas _DARWIN_C_SOURCE makes some symbols visible
that are already visible by default but hidden when _POSIX_C_SOURCE is defined.

The usual idiom in the MacOS X header files is

  #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)

So, I expect that your change will be a no-op for almost everyone.

Bruno
-- 
In memoriam Dmitry Pavlov <http://en.wikipedia.org/wiki/Dmitry_Pavlov_(general)>

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

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org
Cc: 9141 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: fdatasync module proposal
Date: Sat, 23 Jul 2011 04:42:23 +0200

Hi Paul,

> Surely coreutils is not the only program that will have problems
> with fdatasync on Mac OS.  How about the following gnulib patches?
> One is for fdatasync, the other for its tests.

Looks mostly good. Just small comments:

> --- a/lib/unistd.in.h
> +++ b/lib/unistd.in.h
> @@ -483,6 +483,34 @@ _GL_WARN_ON_USE (fchownat, "fchownat is not portable - "
>  #endif
>  
>  
> +#if @GNULIB_FDATASYNC@
> +/* Synchronize data changes to a file.
> +   Return 0 if successful, otherwise -1 and errno set.
> +   See POSIX:2001 specification
> +   <http://www.opengroup.org/susv3xsh/fdatasync.html>.  */

POSIX:2001 is superseded by POSIX:2008. Even if the wording in both standards
is the same for this function, it is good to encourage people to look at and
to refer to the newest standard. So, here I would write

    See POSIX:2008 specification
    <http://www.opengroup.org/onlinepubs/9699919799/functions/fdatasync.html>.  */

> diff --git a/m4/fdatasync.m4 b/m4/fdatasync.m4
> new file mode 100644
> index 0000000..af17970
> --- /dev/null
> +++ b/m4/fdatasync.m4
> @@ -0,0 +1,34 @@
> ...
> +  else
> +    gl_saved_libs=$LIBS
> +      AC_SEARCH_LIBS([fdatasync], [rt posix4],
> +                     [test "$ac_cv_search_fdatasync" = "none required" ||
> +                      LIB_FDATASYNC=$ac_cv_search_fdatasync])
> +      AC_CHECK_FUNCS([fdatasync])
> +    LIBS=$gl_saved_libs

Here one could add a comment like:

       dnl Solaris <= 2.6 has fdatasync() in libposix4.
       dnl Solaris 7..10 has it in librt.

Just for reference, because in 5 years nobody would remember.

> diff --git a/modules/fdatasync b/modules/fdatasync
> new file mode 100644
> index 0000000..94980ec
> --- /dev/null
> +++ b/modules/fdatasync
> ...
> +fsync           [test $HAVE_FDATASYNC = 0]
> +unistd
> +
> +configure.ac:
> +gl_FUNC_FDATASYNC
> +if test $HAVE_FDATASYNC = 0; then

It is safer (w.r.t. future modifications) and more consistent with the
hundreds of other modules to also test $REPLACE_FDATASYNC here:

                   [test $HAVE_FDATASYNC = 0 || test $REPLACE_FDATASYNC = 1]

>    const char *file = "test-fsync.txt";

With this definition, the test-fsync and test-fdatasync programs will write
to the same file. That is, when run with "make -j2", they may collide.
You need to take a different file name for test-fdatasync.

> --- /dev/null
> +++ b/tests/test-fdatasync.c
> @@ -0,0 +1,2 @@
> +#define FSYNC fdatasync
> +#include "test-fsync.c"

> diff --git a/tests/test-fsync.c b/tests/test-fsync.c
> index 2627d0c..6bac01c 100644
> --- a/tests/test-fsync.c
> +++ b/tests/test-fsync.c
> @@ -18,8 +18,12 @@
>  
>  #include <unistd.h>
>  
> +#ifndef FSYNC
> +# define FSYNC fsync
> +#endif
> +
>  #include "signature.h"
> -SIGNATURE_CHECK (fsync, int, (int));
> +SIGNATURE_CHECK (FSYNC, int, (int));
>  
>  #include <errno.h>
>  #include <fcntl.h>
> @@ -32,7 +36,7 @@ main (void)
>    int fd;
>    const char *file = "test-fsync.txt";
>  
> -  if (fsync (0) != 0)
> +  if (FSYNC (0) != 0)
>      {
>        ASSERT (errno == EINVAL /* POSIX */
>                || errno == ENOTSUP /* seen on MacOS X 10.5 */
> @@ -42,7 +46,7 @@ main (void)
>    fd = open (file, O_WRONLY|O_CREAT|O_TRUNC, 0644);
>    ASSERT (0 <= fd);
>    ASSERT (write (fd, "hello", 5) == 5);
> -  ASSERT (fsync (fd) == 0);
> +  ASSERT (FSYNC (fd) == 0);
>    ASSERT (close (fd) == 0);
>    ASSERT (unlink (file) == 0);
>  

Here, like with test-pselect, I would move everything after the signature test
to a separate file, test-fsync.h, that is included by both test-fsync.c and
test-fdatasync.c. This avoids #ifdefs (following the general rule to prefer
C functions over C macros), and gives freedom to add tests that apply to one
of the functions but not both.

Bruno
-- 
In memoriam Dmitry Pavlov <http://en.wikipedia.org/wiki/Dmitry_Pavlov_(general)>

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 9141 <at> debbugs.gnu.org, bug-gnulib <at> gnu.org
Subject: Re: bug#9141: [PATCH 1/3] extensions: Enable extensions on MacOS
	X 10.5	and later.
Date: Sat, 23 Jul 2011 11:34:05 -0700

On 07/22/11 17:23, Bruno Haible wrote:
> The usual idiom in the MacOS X header files is
> 
>   #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
> 
> So, I expect that your change will be a no-op for almost everyone.

Thanks for the clarification.

I looked through what I could glean from Google searches, and
found some places that do not use the above pattern.  For example,
<http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/sys/select.h>
says something like this:

int	 pselect(int, fd_set * __restrict, fd_set * __restrict,
		fd_set * __restrict, const struct timespec * __restrict,
		const sigset_t * __restrict)
#if defined(_DARWIN_C_SOURCE) || defined(_DARWIN_UNLIMITED_SELECT)
		__DARWIN_EXTSN_C(pselect)
#else
#  if defined(__LP64__) && !__DARWIN_NON_CANCELABLE
		__DARWIN_1050(pselect)
#  else
		__DARWIN_ALIAS_C(pselect)
#  endif
#endif
		;

and <http://www.opensource.apple.com/source/Libc/Libc-498.1.7/include/stdlib.h>
says something like this:

#if (__DARWIN_UNIX03 && !defined(_POSIX_C_SOURCE)) || defined(_DARWIN_C_SOURCE) || defined(_DARWIN_BETTER_REALPATH)
char	*realpath(const char * __restrict, char * __restrict) __DARWIN_EXTSN(realpath);
#else
char	*realpath(const char * __restrict, char * __restrict) __DARWIN_ALIAS(realpath);
#endif

which suggests that realpath and pselect have "extended" runtime behavior if
_DARWIN_C_SOURCE is defined.

My guess is that these runtime differences are in the same spirit
as _GNU_SOURCE, i.e., they enable desirable changes that POSIX
would otherwise prohibit.  If so, the patch should be kept.
But if these changes are undesirable, the patch should be backed out.

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

From: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Bug-gnulib <bug-gnulib <at> gnu.org>
Cc: "9141 <at> debbugs.gnu.org" <9141 <at> debbugs.gnu.org>
Subject: RE: bug#9141: [PATCH 1/3] extensions: Enable extensions on MacOS X
	10.5	and later.
Date: Mon, 25 Jul 2011 07:59:04 +0200

Paul Eggert wrote:

> diff --git a/m4/extensions.m4 b/m4/extensions.m4
> index 1330503..22156e0 100644
> --- a/m4/extensions.m4
> +++ b/m4/extensions.m4
> @@ -1,4 +1,4 @@
> -# serial 9  -*- Autoconf -*-
> +# serial 10  -*- Autoconf -*-
>  # Enable extensions on systems that normally disable them.
>  
>  # Copyright (C) 2003, 2006-2011 Free Software Foundation, Inc.
> @@ -67,6 +67,10 @@ AC_BEFORE([$0], [AC_RUN_IFELSE])dnl
>  #ifndef _ALL_SOURCE
>  # undef _ALL_SOURCE
>  #endif
> +/* Enable general extensions on MacOS X.  */
> +#ifndef _DARWIN_C_SOURCE
> +# undef _DARWIN_C_SOURCE
> +#endif

maybe it's too early in the morning for me ... but isn't this a NOP:
"if X is not defined, then undefine it"?

Berny

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Cc: "9141 <at> debbugs.gnu.org" <9141 <at> debbugs.gnu.org>,
	Bug-gnulib <bug-gnulib <at> gnu.org>
Subject: Re: bug#9141: [PATCH 1/3] extensions: Enable extensions on MacOS
	X	10.5	and later.
Date: Sun, 24 Jul 2011 23:05:35 -0700

On 07/24/11 22:59, Voelker, Bernhard wrote:

>>  #ifndef _ALL_SOURCE
>>  # undef _ALL_SOURCE
>>  #endif
>> +/* Enable general extensions on MacOS X.  */
>> +#ifndef _DARWIN_C_SOURCE
>> +# undef _DARWIN_C_SOURCE
>> +#endif
> 
> maybe it's too early in the morning for me ... but isn't this a NOP:
> "if X is not defined, then undefine it"?

Later shell magic edits the file to define it.
In that sense, it's just like _ALL_SOURCE,
which already works.

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

From: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "9141 <at> debbugs.gnu.org" <9141 <at> debbugs.gnu.org>,
	Bug-gnulib <bug-gnulib <at> gnu.org>
Subject: RE: bug#9141: [PATCH 1/3] extensions: Enable extensions on MacOS X
	10.5	and later.
Date: Mon, 25 Jul 2011 08:09:33 +0200

Paul Eggert wrote:

> On 07/24/11 22:59, Voelker, Bernhard wrote:
>
>>>  #ifndef _ALL_SOURCE
>>>  # undef _ALL_SOURCE
>>>  #endif
>>> +/* Enable general extensions on MacOS X.  */
>>> +#ifndef _DARWIN_C_SOURCE
>>> +# undef _DARWIN_C_SOURCE
>>> +#endif
>> 
>> maybe it's too early in the morning for me ... but isn't this a NOP:
>> "if X is not defined, then undefine it"?
>
> Later shell magic edits the file to define it.
> In that sense, it's just like _ALL_SOURCE,
> which already works.

Thanks for the clarification. I knew I should get a cup of coffee
before hitting the 'send' button. ;-)

Have a nice day,
Berny

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eric Blake <eblake <at> redhat.com>
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:02:16 -0700

On 09/16/11 11:28, Eric Blake wrote:
> Do we know this to be the case, or are you just going off of web searches?

The latter.  I just now tried to find that stuff again, and couldn't,
so let's just ignore it for now.  If the problem turns up again
we can fix it later.

The whole fsync/fdatasync/O_SYNC/O_DSYNC/F_FULLSYNC/O_DIRECT/etc. business is
such a poorly-understood zoo that I'm not sure how much it matters ...

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Eric Blake <eblake <at> redhat.com>
Cc: 9141 <at> debbugs.gnu.org
Subject: Re: bug#9141: fdatasync module proposal (WAS: Coreutils Compiler
 Warnings on OSX 10.7)
Date: Mon, 15 Oct 2018 07:45:44 -0600

tags 9141 moreinfo
close 9141
stop

(Triaging old bugs)

On 16/09/11 01:02 PM, Paul Eggert wrote:
> On 09/16/11 11:28, Eric Blake wrote:
>> Do we know this to be the case, or are you just going off of web searches?
> 
> The latter.  I just now tried to find that stuff again, and couldn't,
> so let's just ignore it for now.  If the problem turns up again
> we can fix it later.
> 
> The whole fsync/fdatasync/O_SYNC/O_DSYNC/F_FULLSYNC/O_DIRECT/etc. business is
> such a poorly-understood zoo that I'm not sure how much it matters ...
>

With no further follow-ups in 7 years, I'm closing this bug.

regards,
 - assaf

Previous Next

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