GNU bug report logs - #14463
coreutils-8.21 darwin regressions

Previous Next

Full log

View this message in rfc822 format

From: Jack Howarth <howarth <at> bromo.med.uc.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 14463 <at> debbugs.gnu.org
Subject: bug#14463: coreutils-8.21 darwin regressions
Date: Wed, 13 Nov 2013 09:53:25 -0500

On Sat, May 25, 2013 at 10:22:02AM -0700, Paul Eggert wrote:
> On 05/25/2013 07:51 AM, Jack Howarth wrote:
> > I am a bit unclear on that issue. Does darwin lack the complete posix support required for
> > freadahead.c, freadptr.c, fseterr.c and fseeko.c to be rewritten to support compiling with
> > -D_POSIX_C_SOURCE (at least for modern darwin releases)? Or has it just never been implemented
> > in order to maintain support for legacy versions of darwin?
> 
> Sorry, I don't know Darwin.  But my guess is that applications
> routinely need to define _DARWIN_C_SOURCE to get their work
> done.
> 
> I'm a bit puzzled by this case.  If I understand
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/compat.5.html
> correctly, _DARWIN_C_SOURCE nowadays means "conform to POSIX,
> but add non-POSIX extensions even if that violates the POSIX
> namespace rules", which is normally what we want.  And yet here,
> _DARWIN_C_SOURCE seems to mean "change getgroups() so that it
> no longer works right".  What gives?  If Apple has
> a little "POSIX world" to pacify the standards nerds, but it's
> a world that actual programs would never really want to use,
> then we don't want to use it either.
> 
> The BUGS section of that manual page says that the behavior
> is dubious if you compile different sections of a program with
> different flags, so I'd prefer a solution that didn't require
> disabling _DARWIN_C_SOURCE just for this.

Paul,
   I finally puzzled out a fix for the test-getgroups failures on darwin. The patch I am using
in the fink coreutils-8.21 package currently is...

--- coreutils-8.21/lib/getgroups.c.orig 2013-11-12 16:51:07.000000000 -0500
+++ coreutils-8.21/lib/getgroups.c      2013-11-12 16:52:29.000000000 -0500
@@ -43,6 +43,12 @@
 #  define GETGROUPS_ZERO_BUG 0
 # endif
 
+#ifdef __APPLE__
+#undef getgroups
+int      posix_getgroups(int, gid_t []) __asm("_getgroups");
+#define getgroups posix_getgroups
+#endif
+
 /* On at least Ultrix 4.3 and NextStep 3.2, getgroups (0, NULL) always
    fails.  On other systems, it returns the number of supplemental
    groups for the process.  This function handles that special case

This workaround was previously suggested by the python developers...

http://bugs.python.org/issue7900#msg108425

as a way to force the posix implementation of getgroups() at the source file level without
having to resort to undefining _DARWIN_C_SOURCE. This eliminates the test-getgroups failures
on i386-apple-darwin10, x86_64-apple-darwin10, x86_64-apple-darwin11, x86_64-apple-darwin12
and x86_64-apple-darwin13. Any chance we can get this fix into the next coreutils release?
Thanks in advance.
         Jack

Previous Next

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