On 11/19/2012 08:14 PM, Jim Meyering wrote:
> What do you guys think about a gnulib-tool-time warning
> (or perhaps even a configure-time warning for a non-tarball build)
> when gnulib is more than N days out of date?
I'd vote against it for configure-time. Most warnings
about the future are warn
Eric Blake wrote:
> On 11/19/2012 04:26 PM, matimatik wrote:
>> I cannot find #define for HAVE_RAW_DECL_GETS in it (moreover,
>> 'grep -R HAVE_RAW_DECL_GETS .' in workdir doesn't show anything
>> relevant). But it does contain GNULIB_GETS='1'.
>
> GNULIB_GETS doesn't appear anywhere in current gnul
On Mon, 19 Nov 2012 16:53:30 -0700
Eric Blake wrote:
> [This wouldn't be the first time
> someone has complained that a package suffers from FTBFS when coupled
> with newer glibc, because the package was released with an older
> gnulib snapshot]
Maybe it should be mentioned on savannah page or s
SCM sources builds without problems, so inetutils will be fixed with net
release (just by updating gnulib).
Thanks and sorry for disturbance!
On 11/19/2012 04:26 PM, matimatik wrote:
> I cannot find #define for HAVE_RAW_DECL_GETS in it (moreover,
> 'grep -R HAVE_RAW_DECL_GETS .' in workdir doesn't show anything
> relevant). But it does contain GNULIB_GETS='1'.
GNULIB_GETS doesn't appear anywhere in current gnulib sources. Is your
packag
On Mon, 19 Nov 2012 14:29:56 -0800
Paul Eggert wrote:
> It appears that the problem is that
> HAVE_RAW_DECL_GETS is defined, but 'gets' is
> not actually being declared.
Sorry for disgusting, I just found that inetutils-1.9.1 actually has old
gnulib headers. This is actual stdio.in.h fragment fr
On Mon, 19 Nov 2012 15:08:16 -0700
Eric Blake wrote:
> > #if HAVE_RAW_DECL_GETS
>
> HAVE_RAW_DECL_GETS should only be non-zero if gets() is declared...
>
> > 'gets' undeclared here (not in a function)"
>
> ...but this says gets is undeclared. Are you sure you don't have a
> stale config.cache
On 11/19/2012 03:29 PM, Paul Eggert wrote:
> On 11/19/12 14:02, matimatik wrote:
>> I can grep this line in it:
>>
>> extern __typeof__ (gets) gets __attribute__ ((__warning__ ("gets is a
>> security hole - use fgets instead")));
>
> Thanks. It appears that the problem is that
> HAVE_RAW_DECL_G
On 11/19/12 14:02, matimatik wrote:
> I can grep this line in it:
>
> extern __typeof__ (gets) gets __attribute__ ((__warning__ ("gets is a
> security hole - use fgets instead")));
Thanks. It appears that the problem is that
HAVE_RAW_DECL_GETS is defined, but 'gets' is
not actually being decla
On 11/18/2012 04:03 PM, Ivan Burbakov wrote:
> Building of some packages (inetutils, namely) with glibc-2.16 tends to
> fail because this line:
>
> /* It is very rare that the developer ever has full control of stdin,
>so any use of gets warrants an unconditional warning; besides, C11
>rem
On Mon, 19 Nov 2012 01:20:58 -0800
Paul Eggert wrote:
> On 11/18/2012 03:03 PM, Ivan Burbakov wrote:
> > what is a proper fix?
>
> Hard to say, as there's not enough info there.
I can email any info, just ask.
>
> What's the output of this command? It's one of the failing commands,
> but wit
On 11/18/2012 03:03 PM, Ivan Burbakov wrote:
> what is a proper fix?
Hard to say, as there's not enough info there.
What's the output of this command? It's one of the failing commands,
but with -E replacing -c so that we can see the preprocessor output.
x86_64-pc-linux-gnu-gcc -std=gnu99 -DHAVE
Building of some packages (inetutils, namely) with glibc-2.16 tends to
fail because this line:
/* It is very rare that the developer ever has full control of stdin,
so any use of gets warrants an unconditional warning; besides, C11
removed it. */
#undef gets
#if HAVE_RAW_DECL_GETS
_GL_WARN_
13 matches
Mail list logo
