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

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 14463 in the body.
You can then email your comments to 14463 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: Jack Howarth <howarth <at> bromo.med.uc.edu>
To: bug-coreutils <at> gnu.org
Subject: coreutils-8.21 darwin regressions
Date: Fri, 24 May 2013 09:09:51 -0400

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

   I am finding on x86_64-apple-darwin12 that coreutils 8.21 exhibits four additional failures in gnulib-tests
which aren't present in a build of coreutils 8.19. These are...

FAIL: test-getcwd.sh
FAIL: test-getgroups
FAIL: test-getlogin
FAIL: test-vasprintf-posix

The respective logs shows...

FAIL: test-getcwd.sh (exit: 7)
==============================

FAIL: test-getgroups (exit: 134)
================================

test-getgroups.c:58: assertion failed

FAIL: test-getlogin (exit: 134)
===============================

test-getlogin.c:69: assertion failed

FAIL: test-vasprintf-posix (exit: 134)
======================================

test-vasprintf-posix.c:238: assertion failed

These trace in gdb as...

# gdb ./test-getgroups
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb  6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .. done

(gdb) break main
Breakpoint 1 at 0x1000014a7: file test-getgroups.c, line 39.
(gdb) r
Starting program: /sw/src/fink.build/coreutils-8.21-100/coreutils-8.21/gnulib-tests/test-getgroups 
Reading symbols for shared libraries +............................. done

Breakpoint 1, main (argc=1, argv=0x7fff5fbff7a0) at test-getgroups.c:39
39	  errno = 0;
(gdb) s
40	  result = getgroups (0, NULL);
(gdb) 
rpl_getgroups (n=0, group=0x0) at getgroups.c:70
70	        return getgroups (n, (GETGROUPS_T *) group);
(gdb) 
Current language:  auto; currently minimal
0x0000000100001cfc in dyld_stub_getgroups$DARWIN_EXTSN ()
(gdb) 
Single stepping until exit from function dyld_stub_getgroups$DARWIN_EXTSN, 
which has no line number information.
test-getgroups.c:58: assertion failed

Program received signal SIGABRT, Aborted.
0x00007fff885b4d46 in __kill ()
(gdb) 

# gdb ./test-getlogin
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb  6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .. done

(gdb) break main
Breakpoint 1 at 0x100000894: file test-getlogin.c, line 39.
(gdb) r
Starting program: /sw/src/fink.build/coreutils-8.21-100/coreutils-8.21/gnulib-tests/test-getlogin 
Reading symbols for shared libraries +............................. done

Breakpoint 1, main () at test-getlogin.c:39
39	  buf = getlogin ();
(gdb) s
40	  if (buf == NULL)
(gdb) s
65	    const char *name = getenv ("LOGNAME");
(gdb) s
66	    if (name == NULL || name[0] == '\0')
(gdb) s
68	    if (name != NULL && name[0] != '\0')
(gdb) s
69	      ASSERT (strcmp (buf, name) == 0);
(gdb) s
test-getlogin.c:69: assertion failed
rpl_fflush (stream=0x7fff76c23bc0) at fflush.c:145
145	  if (stream == NULL || ! freading (stream))
(gdb) s
Current language:  auto; currently minimal
freading (fp=0x7fff76c23bc0) at freading.c:39
39	  return (fp_->_flags & __SRD) != 0;
(gdb) s
rpl_fflush (stream=0x7fff76c23bc0) at fflush.c:146
146	    return fflush (stream);
(gdb) s
0x0000000100000cd2 in dyld_stub_fflush ()
(gdb) s
Single stepping until exit from function dyld_stub_fflush, 
which has no line number information.

Program received signal SIGABRT, Aborted.
0x00007fff885b4d46 in __kill ()
(gdb) 

The full trace for the test-vasprintf-posix test case is rather large and is attached as a gzip file.
         Jack

[test-vasprintf-posix.trace.gz (application/x-gzip, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jack Howarth <howarth <at> bromo.med.uc.edu>
Cc: 14463 <at> debbugs.gnu.org
Subject: Re: bug#14463: coreutils-8.21 darwin regressions
Date: Fri, 24 May 2013 10:37:55 -0700

On 05/24/2013 06:09 AM, Jack Howarth wrote:
>    I am finding on x86_64-apple-darwin12 that coreutils 8.21 exhibits four additional failures in gnulib-tests
> which aren't present in a build of coreutils 8.19. These are...

> test-getgroups.c:58: assertion failed

Thanks, this makes it looks like Darwin getgroups (n, array)
isn't returning -1 when the user is in more than n groups.
I see from the manual that the Darwin has two getgroups
implementations, one when you define _DARWIN_UNLIMITED_GETGROUPS or
_DARWIN_C_SOURCE, and one when you don't.  Which one are you
using, and why?  And does the one you're using have the
above-described property?  If so, I suppose Gnulib could
be modified to work around the POSIX incompatibility.

> test-getlogin.c:69: assertion failed

What are the values of 'buf' and of 'name' there, and why?

> The full trace for the test-vasprintf-posix test case is rather large and is attached as a gzip file.

It's failing here:


  { /* Rounding near the decimal point.  */
    char *result;
    int retval =
      my_asprintf (&result, "%.0a %d", 1.5, 33, 44, 55);
    ASSERT (result != NULL);
    ASSERT (strcmp (result, "0x1p+0 33") == 0
            || strcmp (result, "0x2p+0 33") == 0
            || strcmp (result, "0x3p-1 33") == 0
            || strcmp (result, "0x6p-2 33") == 0
            || strcmp (result, "0xcp-3 33") == 0);
    ASSERT (retval == strlen (result));
    free (result);
  }

Can you run GDB on that and see what the value of 'result' is?
Most likely it's just the Apple sprintf messing up.

You mentioned a getcwd problem, but I didn't see any
more details....

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

From: Jack Howarth <howarth <at> bromo.med.uc.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 14463 <at> debbugs.gnu.org
Subject: Re: bug#14463: coreutils-8.21 darwin regressions
Date: Fri, 24 May 2013 18:46:35 -0400

On Fri, May 24, 2013 at 10:37:55AM -0700, Paul Eggert wrote:
> On 05/24/2013 06:09 AM, Jack Howarth wrote:
> >    I am finding on x86_64-apple-darwin12 that coreutils 8.21 exhibits four additional failures in gnulib-tests
> > which aren't present in a build of coreutils 8.19. These are...
> 
> > test-getgroups.c:58: assertion failed
> 
> Thanks, this makes it looks like Darwin getgroups (n, array)
> isn't returning -1 when the user is in more than n groups.
> I see from the manual that the Darwin has two getgroups
> implementations, one when you define _DARWIN_UNLIMITED_GETGROUPS or
> _DARWIN_C_SOURCE, and one when you don't.  Which one are you
> using, and why?  And does the one you're using have the
> above-described property?  If so, I suppose Gnulib could
> be modified to work around the POSIX incompatibility.

It obviously wlll be using _DARWIN_C_SOURCE because that is what you test for in
m4/extensions.m4 with...

AC_DEFINE([_DARWIN_C_SOURCE])

The following posting from bugs.python.org seems to discuss this same issue...

http://mail.python.org/pipermail/python-bugs-list/2010-February/092780.html

The proposed fix there was to revert _DARWIN_C_SOURCE locally in only posixmodule.c.
I tried changing the instances of _DARWIN_C_SOURCE to _POSIX_C_SOURCE in configure, lib/config.hin
and m4/extensions.m4 but that build fails with...

  CC     lib/fts.o
lib/freadahead.c:91:3: error: "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then
      report this to bug-gnulib."
 #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."
  ^
1 error generated.
lib/freadptr.c:116:3: error: "Please port gnulib freadptr.c to your platform! Look at the definition of fflush, fread, getc, getc_unlocked on your system,
      then report this to bug-gnulib."
make[2]: *** [lib/freadahead.o] Error 1
make[2]: *** Waiting for unfinished jobs....
 #error "Please port gnulib freadptr.c to your platform! Look at the definition of fflush, fread, getc, getc_unlocked on your system, then report...
  ^
1 error generated.
make[2]: *** [lib/freadptr.o] Error 1
lib/fseterr.c:77:3: error: "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this
      to bug-gnulib."
 #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib."
  ^
1 error generated.
lib/fseeko.c:103:4: error: "Please port gnulib fseeko.c to your platform! Look at the code in fpurge.c, then report this to bug-gnulib."
  #error "Please port gnulib fseeko.c to your platform! Look at the code in fpurge.c, then report this to bug-gnulib."
   ^
1 error generated.
make[2]: *** [lib/fseterr.o] Error 1
make[2]: *** [lib/fseeko.o] Error 1
lib/fts.c:1217:10: error: use of undeclared identifier 'DT_BLK'
    case DT_BLK:
         ^
lib/fts.c:1220:10: error: use of undeclared identifier 'DT_CHR'
    case DT_CHR:
         ^
lib/fts.c:1223:10: error: use of undeclared identifier 'DT_DIR'
    case DT_DIR:
         ^
lib/fts.c:1226:10: error: use of undeclared identifier 'DT_FIFO'
    case DT_FIFO:
         ^
lib/fts.c:1229:10: error: use of undeclared identifier 'DT_LNK'
    case DT_LNK:
         ^
lib/fts.c:1232:10: error: use of undeclared identifier 'DT_REG'
    case DT_REG:
         ^
lib/fts.c:1235:10: error: use of undeclared identifier 'DT_SOCK'
    case DT_SOCK:
         ^
lib/fts.c:1532:46: error: use of undeclared identifier 'DT_UNKNOWN'
                                          && DT_IS_KNOWN(dp)
                                             ^
lib/fts.c:88:41: note: expanded from macro 'DT_IS_KNOWN'
# define DT_IS_KNOWN(d) ((d)->d_type != DT_UNKNOWN)
                                        ^
lib/fts.c:1533:63: error: use of undeclared identifier 'DT_DIR'
                                          && ! DT_MUST_BE(dp, DT_DIR));
                                                              ^
lib/fts.c:90:44: note: expanded from macro 'DT_MUST_BE'
# define DT_MUST_BE(d, t) ((d)->d_type == (t))
                                           ^
lib/fts.c:1540:53: error: use of undeclared identifier 'DT_DIR'
                                  && DT_MUST_BE(dp, DT_DIR));
                                                    ^
lib/fts.c:90:44: note: expanded from macro 'DT_MUST_BE'
# define DT_MUST_BE(d, t) ((d)->d_type == (t))
                                           ^
10 errors generated.

≈
> 
> > test-getlogin.c:69: assertion failed
> 
> What are the values of 'buf' and of 'name' there, and why?
> 
> > The full trace for the test-vasprintf-posix test case is rather large and is attached as a gzip file.
> 
> It's failing here:
> 
> 
>   { /* Rounding near the decimal point.  */
>     char *result;
>     int retval =
>       my_asprintf (&result, "%.0a %d", 1.5, 33, 44, 55);
>     ASSERT (result != NULL);
>     ASSERT (strcmp (result, "0x1p+0 33") == 0
>             || strcmp (result, "0x2p+0 33") == 0
>             || strcmp (result, "0x3p-1 33") == 0
>             || strcmp (result, "0x6p-2 33") == 0
>             || strcmp (result, "0xcp-3 33") == 0);
>     ASSERT (retval == strlen (result));
>     free (result);
>   }
> 
> Can you run GDB on that and see what the value of 'result' is?
> Most likely it's just the Apple sprintf messing up.
> 
> You mentioned a getcwd problem, but I didn't see any
> more details....
> 
> 

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jack Howarth <howarth <at> bromo.med.uc.edu>
Cc: 14463 <at> debbugs.gnu.org
Subject: Re: bug#14463: coreutils-8.21 darwin regressions
Date: Sat, 25 May 2013 01:59:20 -0700

On 05/24/2013 03:46 PM, Jack Howarth wrote:
> I tried changing the instances of _DARWIN_C_SOURCE to _POSIX_C_SOURCE in configure

That won't work, for the reasons you describe.

How about this idea: modify getgroups.m4 to recognize
the Darwin situation and compile a substitute getgroups.c,
and modify getgroups.c to work around the Darwin problem
by defining a rpl_getgroups that calls the correct Darwin
getgroups.  It'll take a bit of Darwinish hacking to get
this to work, but it should work.

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

From: Jack Howarth <howarth <at> bromo.med.uc.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 14463 <at> debbugs.gnu.org
Subject: Re: bug#14463: coreutils-8.21 darwin regressions
Date: Sat, 25 May 2013 10:51:55 -0400

On Sat, May 25, 2013 at 01:59:20AM -0700, Paul Eggert wrote:
> On 05/24/2013 03:46 PM, Jack Howarth wrote:
> > I tried changing the instances of _DARWIN_C_SOURCE to _POSIX_C_SOURCE in configure
> 
> That won't work, for the reasons you describe.

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?

> 
> How about this idea: modify getgroups.m4 to recognize
> the Darwin situation and compile a substitute getgroups.c,
> and modify getgroups.c to work around the Darwin problem
> by defining a rpl_getgroups that calls the correct Darwin
> getgroups.  It'll take a bit of Darwinish hacking to get
> this to work, but it should work.
> 
> 

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jack Howarth <howarth <at> bromo.med.uc.edu>
Cc: 14463 <at> debbugs.gnu.org
Subject: Re: bug#14463: coreutils-8.21 darwin regressions
Date: Sat, 25 May 2013 10:22:02 -0700

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.

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

From: Jack Howarth <howarth <at> bromo.med.uc.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 14463 <at> debbugs.gnu.org
Subject: Re: bug#14463: coreutils-8.21 darwin regressions
Date: Sat, 25 May 2013 16:12:02 -0400

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.

I think the _DARWIN_UNLIMITED_GETGROUPS issue may be a red herring. Passing -D_DARWIN_UNLIMITED_GETGROUPS
to CFLAGS didn't eliminate any of the failures and the only instance of _DARWIN_UNLIMITED_GETGROUPS in
the headers in /usr/include for Mac OS X 10.8  are in unistd.h. These are...

#ifdef _DARWIN_UNLIMITED_GETGROUPS
#if defined(__IPHONE_OS_VERSION_MIN_REQUIRED) && __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_3_2
#error "_DARWIN_UNLIMITED_GETGROUPS specified, but -miphoneos-version-min version does not support it."
#elif defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && __MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_6
#error "_DARWIN_UNLIMITED_GETGROUPS specified, but -mmacosx-version-min version does not support it."
#endif
#endif

and

#if defined(_DARWIN_UNLIMITED_GETGROUPS) || defined(_DARWIN_C_SOURCE)
int      getgroups(int, gid_t []) __DARWIN_ALIAS_STARTING(__MAC_10_6, __IPHONE_3_2, __DARWIN_EXTSN(getgroups));
#else /* !_DARWIN_UNLIMITED_GETGROUPS && !_DARWIN_C_SOURCE */
int      getgroups(int, gid_t []);
#endif /* _DARWIN_UNLIMITED_GETGROUPS || _DARWIN_C_SOURCE */

which sugggests that _DARWIN_C_SOURCE and _DARWIN_UNLIMITED_GETGROUPS use the same extension for getgroups.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jack Howarth <howarth <at> bromo.med.uc.edu>
Cc: 14463 <at> debbugs.gnu.org
Subject: Re: bug#14463: coreutils-8.21 darwin regressions
Date: Sat, 25 May 2013 13:14:43 -0700

On 05/25/2013 01:12 PM, Jack Howarth wrote:
> __DARWIN_ALIAS_STARTING(__MAC_10_6, __IPHONE_3_2, __DARWIN_EXTSN(getgroups))

What does this expand to, and why?  Is there some way that we can get it
to expand to nothing (no tokens), without changing the expansion of
anything else?  For example, how does __DARWIN_EXTSN(getgroups) work?

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

From: Jack Howarth <howarth <at> bromo.med.uc.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 14463 <at> debbugs.gnu.org
Subject: Re: 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

Message #34 received at 14463-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jack Howarth <howarth <at> bromo.med.uc.edu>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 14463-done <at> debbugs.gnu.org
Subject: Re: bug#14463: coreutils-8.21 darwin regressions
Date: Wed, 13 Nov 2013 07:57:28 -0800

Thanks, I pushed the following patch to gnulib.  It should be
incorporated automatically into the next version of coreutils
so I'm marking the bug as done.

diff --git a/ChangeLog b/ChangeLog
index 59de3e5..aae8c64 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2013-11-13  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	* lib/getgroups.c (posix_getgroups, getgroups) [__APPLE__]:
+	New function and macro, to work around _DARWIN_C_SOURCE problem.
+	Reported by Jack Howarth in <http://bugs.gnu.org/14463>.
+
 2013-11-11  Pádraig Brady <P <at> draigBrady.com>
 
 	base64: provide a fast path for encoding well sized buffers
diff --git a/lib/getgroups.c b/lib/getgroups.c
index e71b543..482b24a 100644
--- a/lib/getgroups.c
+++ b/lib/getgroups.c
@@ -43,6 +43,21 @@ getgroups (int n _GL_UNUSED, GETGROUPS_T *groups _GL_UNUSED)
 #  define GETGROUPS_ZERO_BUG 0
 # endif
 
+/* On OS X 10.6 and later, use the usual getgroups, not the one
+   supplied when _DARWIN_C_SOURCE is defined.  _DARWIN_C_SOURCE is
+   normally defined, since it means "conform to POSIX, but add
+   non-POSIX extensions even if that violates the POSIX namespace
+   rules", which is what we normally want.  But with getgroups there
+   is an inconsistency, and _DARWIN_C_SOURCE means "change getgroups()
+   so that it no longer works right".  The BUGS section of compat(5)
+   says that the behavior is dubious if you compile different sections
+   of a program with different _DARWIN_C_SOURCE settings, so fix only
+   the offending symbol.  */
+# ifdef __APPLE__
+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

Previous Next

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