> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Wed, 31 May 2017 00:17:14 -0400
>
>
> Eli Zaretskii writes:
> > Seems to work fine, thanks.
>
> Checked into gcc trunk then :-)
Thanks!
Eli Zaretskii writes:
> Seems to work fine, thanks.
Checked into gcc trunk then :-)
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Fri, 26 May 2017 17:34:12 -0400
>
>
> Please try this patch:
Seems to work fine, thanks.
Please try this patch:
Index: config.in
===
--- config.in (revision 248482)
+++ config.in (working copy)
@@ -76,12 +76,16 @@
#undef HAVE_DECL_SBRK
/* Define to 1 if you have the declaration of `snprintf', and to 0 if you
On 05/20/2017 01:38 AM, DJ Delorie wrote:
>
> Pedro Alves writes:
>> Ah, yeah. AFAICS, all the declaration checks in libiberty.h are
>> HAVE_DECL checks. This suggests to me that this declaration guard
>> should be HAVE_DECL too [1].
>
> Except the ones in the $funcs list, which includes str
Pedro Alves writes:
> Ah, yeah. AFAICS, all the declaration checks in libiberty.h are
> HAVE_DECL checks. This suggests to me that this declaration guard
> should be HAVE_DECL too [1].
Except the ones in the $funcs list, which includes strnlen. I think in
the old days, we didn't put in decl
On 05/19/2017 11:31 PM, DJ Delorie wrote:
>
> Right, I meant, libiberty's configure, gcc's configure, binutils'
> configure, and gdb's configure, all need to agree on whether strnlen is
> a HAVE or a HAVE_DECL type symbol. If they don't, the header can't
> provide "one" working solution.
>
Ah,
Right, I meant, libiberty's configure, gcc's configure, binutils'
configure, and gdb's configure, all need to agree on whether strnlen is
a HAVE or a HAVE_DECL type symbol. If they don't, the header can't
provide "one" working solution.
On 05/19/2017 10:56 PM, DJ Delorie wrote:
>
> Eli Zaretskii writes:
>> It should use HAVE_STRNLEN instead, because that's the only
>> strnlen-related macro defined in config.g when strnlen is probed by
>> the configure script.
>
> Ah, but gcc's configure defines HAVE_DECL_STRNLEN. Header guards
Eli Zaretskii writes:
> It should use HAVE_STRNLEN instead, because that's the only
> strnlen-related macro defined in config.g when strnlen is probed by
> the configure script.
Ah, but gcc's configure defines HAVE_DECL_STRNLEN. Header guards need
to be coordinated across all the users, not jus
On 05/19/2017 04:40 PM, Eli Zaretskii wrote:
>> Cc: gdb-patc...@sourceware.org, Thomas Schwinge
>> From: Pedro Alves
>> Date: Fri, 19 May 2017 16:22:55 +0100
>>
>> But then, xstrndup.c has at the top:
>>
>> #ifdef HAVE_STRING_H
>> #include
>> #else
>> # ifdef HAVE_STRINGS_H
>> # include
>> # e
> Cc: gdb-patc...@sourceware.org, Thomas Schwinge
> From: Pedro Alves
> Date: Fri, 19 May 2017 16:22:55 +0100
>
> But then, xstrndup.c has at the top:
>
> #ifdef HAVE_STRING_H
> #include
> #else
> # ifdef HAVE_STRINGS_H
> # include
> # endif
> #endif
>
> So I would expect your build to pick
[Adding Thomas]
On 05/08/2017 04:30 PM, Eli Zaretskii wrote:
> When compiling libiberty (as part of GDB) with MinGW on MS-Windows, I
> see the following warning:
>
> gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I.
> -I./../include -W -Wall -Wwrite-strings -Wc++-compat -
13 matches
Mail list logo