> 1. This code isn't used - due to the combination of #if's.
Sorry if I'm missing the point here, but FWIW, my suggestion for
cpp-related debugging is to take the line from make for compiling the
file and change it to:
gcc -E -dD -o foobar ...copy rest of cmdline from make output...
Then foo
On 01/28/2013 11:30 AM, Assaf Gordon wrote:
> 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
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".
>
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 a
An ugly work-around:
"-O1" seems to overcome the messy macro expansion of stpncpy.
So either compile everything with CFLAGS="-g -O1",
Or compile everything with "-g -O0" until it fails, then compile two
problematic objects with "-O1" and continue,
Or just compile the program of interest and igno
Paul Eggert wrote, On 01/24/2013 04:38 PM:
> On 01/24/13 13:07, Assaf Gordon wrote:
>> $ CFLAGS="-g -O0" ./configure
>
> Isn't it better to use this?
>
>./configure CFLAGS="-g -O0"
>
> If that works, it solves your problem.
No, doesn't work - same linking error.
> Otherwise:
>
>> $ ma
On 01/24/13 13:07, Assaf Gordon wrote:
> $ CFLAGS="-g -O0" ./configure
Isn't it better to use this?
./configure CFLAGS="-g -O0"
If that works, it solves your problem.
Otherwise:
> $ make
> [ ... snip ... ]
> CCLD src/dircolors
> Undefined symbols for architecture x86_64:
>
Paul Eggert wrote, On 01/22/2013 01:20 AM:
> On 01/21/2013 11:39 AM, Assaf Gordon wrote:
>> This fixes the problem. Compilation succeeds with both gcc and clang.
>
> Thanks for checking. I pushed the following patch into gnulib
> and am marking this coreutils bug as done.
>
Just a follow-up, no
On 01/21/2013 11:39 AM, Assaf Gordon wrote:
> This fixes the problem. Compilation succeeds with both gcc and clang.
Thanks for checking. I pushed the following patch into gnulib
and am marking this coreutils bug as done.
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2013-01-21 Paul Eggert
