I sync'd coreutils to use the latest from gnulib
and tried to build. To my horror, I saw this:
cc1: warnings being treated as errors
readtokens.c: In function 'readtoken':
readtokens.c:118: error: implicit declaration of function 'x2nrealloc'
[-Wimplicit-function-declaration]
readtokens.
Eric Blake wrote:
...
> s/futimes/futimens/ (ChangeLog and commit message)
Thanks!
>> +++ b/lib/utimens.c
>> @@ -264,19 +264,20 @@ fdutimens (char const *file, int fd, struct timespec
>> const timespec[2])
>> }
>> # endif /* HAVE_UTIMENSAT */
>> # if HAVE_FUTIMENS
>> - {
>> -
SIGNATURE_CHECK fails a few tests due to undefined ssize_t, and pread,
on my GNU/Linux system.
Not sure if the patch is right, or if the ssize_t module is needed.
The pread failure is without a patch; it requires
#define _XOPEN_SOURCE 500
here but I'm not sure what the right gnuliby fix is: an
Existence of leftover conftest.lnk2 file from readlink test breaks the
gl_FUNC_SYMLINK test (wrongly returning 2 instead of 0). OK to commit?
Cheers,
Ralf
* m4/readlink.m4 (gl_FUNC_READLINK): Remove conftest.lnk2,
to avoid failure of symlink test later.
diff --git a/m4/readlink.
Hello,
* Jim Meyering wrote on Tue, Jan 05, 2010 at 07:09:57PM CET:
> Paolo Bonzini wrote:
> > On 01/04/2010 03:03 PM, Jim Meyering wrote:
> >> However, it would be far better if AC_CHECK_FUNCS_ONCE
> >> were to expand to e.g., ":" rather than the empty string,
> >> so that it can be used unadorne
The announcement target of maint.mk failed unnecessarily in a VPATH tree.
I noticed this while syncing modern gnulib maint.mk into autoconf, which
already had this patch:
--
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
From aab6ab6d121b644d99c3cf6390
According to Dilyan Palauzov on 1/5/2010 11:13 AM:
> My question is, if gnulib has replacement for strcasecmp () that is not
> documented, or if gnulib has no replacement at all?
The documentation was out-of-date. (And your subject line didn't help
matters - the question is about strcasecmp, not
According to Jim Meyering on 1/5/2010 2:07 PM:
>> https://bugzilla.redhat.com/show_bug.cgi?id=552320
> Thanks for the heads up. Good timing.
> That does indeed look like a bug, and Aurelien Jarno's fix seems right.
I can confirm that the fix is correct.
>
> I expect to push the following to gnu
Bruno Haible wrote:
> Hi Paolo,
>
>> Before proceeding, however, I'm curious whether using nl_langinfo
>> (CODESET) is less precise than locale_charset on some platform. Bruno?
>
> Here's my reply to Jim from yesterday. For some reason it was apparently
> not distributed to the mailing list.
>
> H
bugzi...@redhat.com wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=552320
>
> Ondrej Vasik changed:
>
>What|Removed |Added
>
> CC||j..
Hello,
The documentation of gnulib states, that there is no gnulib module,
that replaces strcasecmp (). At least this is my understanding for
http://www.gnu.org/software/gnulib/manual/html_node/strcasecmp.html#strcasecmp
.
But at the same time the strcase module seems to implement strcase
Hi Paolo,
> Before proceeding, however, I'm curious whether using nl_langinfo
> (CODESET) is less precise than locale_charset on some platform. Bruno?
Here's my reply to Jim from yesterday. For some reason it was apparently
not distributed to the mailing list.
Hi Jim,
> @@ -893,7 +896,9 @@ in
On 01/05/2010 07:02 PM, Jim Meyering wrote:
Is langinfo.h universally available, these days?
And is CODESET always defined?
With glibc or gnulib, yes and yes. The portability to other systems is
bitrotten anyway.
Paolo
One tweak required: include unconditionally:
This cleanup is possible too. Also, the unconditional inclusion of
langinfo.h should be sent to glibc as well.
Before proceeding, however, I'm curious whether using nl_langinfo
(CODESET) is less precise than locale_charset on some platform.
Ludovic Courtès wrote:
> Surprisingly “make dist” has been failing on Hydra for some time[*]:
>
> gcc -std=gnu99 -I. -g -O2 -c -o exclude.o exclude.c
> In file included from mbuiter.h:106,
> from exclude.c:38:
> mbchar.h: In function 'mb_width_aux':
> mbchar.h:241: warning: i
Paolo Bonzini wrote:
> On 01/04/2010 03:03 PM, Jim Meyering wrote:
>> Testing my proposed make-regex-use-nl_langinfo changes,
>> I encountered this configure failure:
>> ...
>> checking whether is self-contained... yes
>> ./configure: line 31968: syntax error near unexpected token `
Paolo Bonzini wrote:
>> One tweak required: include unconditionally:
>
> This cleanup is possible too. Also, the unconditional inclusion of
> langinfo.h should be sent to glibc as well.
Is langinfo.h universally available, these days?
And is CODESET always defined?
I didn't think so, but haven
On 01/04/2010 03:03 PM, Jim Meyering wrote:
Testing my proposed make-regex-use-nl_langinfo changes,
I encountered this configure failure:
...
checking whether is self-contained... yes
./configure: line 31968: syntax error near unexpected token `else'
./configure: line 31968:
Eric Blake wrote:
> Jim Meyering meyering.net> writes:
>
>> >> Subject: [PATCH 3/3] maint: remove useless inclusions of "alloca.h"
>> >>
>> >> * lib/getloadavg.c: Remove useless inclusion of "alloca.h".
>> >> * lib/readtokens.c: Likewise.
>> >> * lib/same.c: Likewise.
>> >> * modules/getloadavg (D
Jim Meyering meyering.net> writes:
> >> Subject: [PATCH 3/3] maint: remove useless inclusions of "alloca.h"
> >>
> >> * lib/getloadavg.c: Remove useless inclusion of "alloca.h".
> >> * lib/readtokens.c: Likewise.
> >> * lib/same.c: Likewise.
> >> * modules/getloadavg (Depends-on): Remove alloca.
Eric Blake wrote:
> According to Jim Meyering on 1/5/2010 7:20 AM:
>> Subject: [PATCH 3/3] maint: remove useless inclusions of "alloca.h"
>>
>> * lib/getloadavg.c: Remove useless inclusion of "alloca.h".
>> * lib/readtokens.c: Likewise.
>> * lib/same.c: Likewise.
>> * modules/getloadavg (Depends-o
According to Jim Meyering on 1/5/2010 7:20 AM:
> Subject: [PATCH 3/3] maint: remove useless inclusions of "alloca.h"
>
> * lib/getloadavg.c: Remove useless inclusion of "alloca.h".
> * lib/readtokens.c: Likewise.
> * lib/same.c: Likewise.
> * modules/getloadavg (Depends-on): Remove alloca.
s/allo
John W. Eaton wrote:
> Although lib/mkdir.c includes xalloc.h, the mkdir module doesn't
> depend on xalloc. Should it? If so, how about the following change?
Thanks for spotting that!
As you saw from Eric's reply, the inclusion of alloca.h was unnecessary.
This highlights a slightly larger prob
According to John W. Eaton on 1/5/2010 1:53 AM:
> Although lib/mkdir.c includes xalloc.h, the mkdir module doesn't
> depend on xalloc. Should it? If so, how about the following change?
Thanks for the report. mkdir should _not_ depend on xalloc. It is wrong
for system call wrappers to call exit
Although lib/mkdir.c includes xalloc.h, the mkdir module doesn't
depend on xalloc. Should it? If so, how about the following change?
Thanks,
jwe
>From 78ed1c4cd10f5ef982ab09a2f19d31a786bf4cbe Mon Sep 17 00:00:00 2001
From: John W. Eaton
Date: Tue, 5 Jan 2010 03:50:42 -0500
Subject: [PATCH] mk
25 matches
Mail list logo
