[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#13495: Compilation fails on Mac OS X 10.8.0
From: |
Assaf Gordon |
Subject: |
Re: bug#13495: Compilation fails on Mac OS X 10.8.0 |
Date: |
Mon, 28 Jan 2013 14:30:59 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 |
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.