GNU bug report logs - #13495
Compilation fails on Mac OS X 10.8.0

Previous Next

Package: coreutils;

Reported by: Assaf Gordon <assafgordon <at> gmail.com>

Date: Fri, 18 Jan 2013 22:34:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log

View this message in rfc822 format

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-gnulib <bug-gnulib <at> gnu.org>, 13495 <at> debbugs.gnu.org
Subject: bug#13495: Compilation fails on Mac OS X 10.8.0
Date: Mon, 28 Jan 2013 14:30:59 -0500

Paul Eggert wrote, On 01/25/2013 05:18 PM:
> On 01/25/2013 11:25 AM, Assaf Gordon wrote:
> 
>> So I'm guessing that even though gnulib's stpncpy code is used,
>> because the MacOS's native declaration of stpncpy is included, it
>> causes problems when the macro is expanded to use "__stpncpy_chk".
> 
> Does the following patch fix things for you?  It attempts to change
> the substitute string.h to inhibit that macro expansion.
> 

No, doesn't work, on two levels:

1. This code isn't used - due to the combination of #if's.
The resulting "lib/string.h" contains:
    /* Copy no more than N bytes of SRC to DST, returning a pointer past the
       last non-NUL byte written into DST.  */
    #if 1
    # if 0 || (!0 && defined stpncpy)
    #  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
    #   undef stpncpy
    #   define stpncpy rpl_stpncpy
    #  endif
    # endif

And this isn't used. I checked by adding an "#error" above the "#undef" - and it didn't trigger an error.

2. I took the two lines (undef+defined) and put them outside the #if's (and verified they were processed, using #error) - but they still did not fix the compilation error.
This bug report was last modified 12 years and 113 days ago.

Previous Next

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