Re: more warnings patrol

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 10/30/2009 6:43 PM: > Hi Eric, > >> --- a/lib/mktime.c >> +++ b/lib/mktime.c >> @@ -147,6 +147,9 @@ const unsigned short int __mon_yday[2][13] = >> # undef __localtime_r >> # define __localtime_r localtime_r >> # define

Re: more warnings patrol

Hi Eric, > --- a/lib/mktime.c > +++ b/lib/mktime.c > @@ -147,6 +147,9 @@ const unsigned short int __mon_yday[2][13] = > # undef __localtime_r > # define __localtime_r localtime_r > # define __mktime_internal mktime_internal > +time_t __mktime_internal (struct tm *, > + s

Re: autoconf-only projects and gnulib?

Karl Berry wrote: > Would it be at all feasible for gnulib to support non-automake (just > autoconf) projects? If the answer is "not at all feasible", that's ok. > I'm just asking, not requesting. gnulib can be used in projects which don't use Makefile.am so far. But gnulib-tool will create the f

Re: bootstrap diagnostics: grep: amsnippet.tmp: No such file or directory

Jim Meyering wrote: > FYI, before I forget (can't investigate right now)... > > Running bootstrap for GNU parted, I saw this on fedora rawhide: > > Copying file ._bootmp/m4/xstrtol.m4 > grep: amsnippet.tmp: No such file or directory > grep: amsnippet.tmp: No such file or directory > grep:

more warnings patrol

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm committing this, to silence some unused variables, and to make inttostr.c quiet even on older gcc. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (

autoconf-only projects and gnulib?

Would it be at all feasible for gnulib to support non-automake (just autoconf) projects? If the answer is "not at all feasible", that's ok. I'm just asking, not requesting. (I have a potential GNU package whose maintainer already knows autoconf, but not automake. It would be nice if he could use

Re: stat() replacement with _LARGE_FILES on AIX

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 10/30/2009 10:44 AM: > Nope, you've done enough. Thanks! Now all I have to do is test that your > patch doesn't break Linux or Solaris (that is, either autoconf doesn't set > _LARGE_FILES for those platforms, or the use o

Re: [PATCH] exclude: avoid an unwarranted warning

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Sergey Poznyakoff on 10/30/2009 10:52 AM: > Eric Blake ha escrit: > >> Like this? > > Yes, it was one of the ways Jim suggested earlier. See > http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00435.html OK then, I've committed t

Re: more test suite problems

Hi Eric, Eric Blake writes: > Subject: [PATCH] fseek: avoid compilation failure when fflush is replaced > * m4/fseeko.m4 (gl_REPLACE_FSEEKO): Also replace fseek, if fseek > module is in use. > --- a/m4/fseeko.m4 > +++ b/m4/fseeko.m4 > @@ -15,7 +15,7 @@ AC_DEFUN([gl_FUNC_FSEEKO], > >AC_CACH

Re: [PATCH] exclude: avoid an unwarranted warning

Eric Blake ha escrit: > Like this? Yes, it was one of the ways Jim suggested earlier. See http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00435.html Regards, Sergey

Re: stat() replacement with _LARGE_FILES on AIX

Michael Haubenwallner salomon.at> writes: > > If stat is defined, we can't be positive it was defined to stat64 or some > > other spelling, like __stat64. I'd feel safer blindly replacing all known > > spellings, as and when we encounter them. > > Fine with me. > > > So that I can fully unders

vasnprintf warnings

Bruno, is it okay to apply this patch to silence these compiler warnings? | vasnprintf.c:2378: warning: declaration of 'buf' shadows a previous local | vasnprintf.c:1502: warning: shadowed declaration is here Here, using two different local variables buf with different types and nested scopes is

Re: Explicit interpreter paths considered harmful

Excellent, thank you all! Ludo’.

Re: Explicit interpreter paths considered harmful

Jim Meyering wrote: > Ludovic Courtès wrote: >> Works like a charm on NixOS, both with ./gitlog-to-changelog and “perl >> gitlog-to-changelog”, thanks! > > Good! > ... >> While you’re at it, can you update the other scripts under ‘build-aux’ >> that use /usr/bin/perl? > > Of course. Pushed like th

Re: Explicit interpreter paths considered harmful

Hi Simon, Simon Josefsson writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Here's a patch. >> >> Likewise, ‘pmccabe2html’ assumes /usr/bin/awk, but I’m not sure what to >> do here: > > See the documentation in pmccabe2html -- the recommended way to use the > script is already using $(AWK).

Re: Explicit interpreter paths considered harmful

Ludovic Courtès wrote: > Works like a charm on NixOS, both with ./gitlog-to-changelog and “perl > gitlog-to-changelog”, thanks! Good! ... > While you’re at it, can you update the other scripts under ‘build-aux’ > that use /usr/bin/perl? Of course.

Re: Explicit interpreter paths considered harmful

Hi, Jim Meyering writes: > From f8a4d66d651f505d0cd349a7c0be025f1b2e12d0 Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Fri, 30 Oct 2009 15:02:02 +0100 > Subject: [PATCH] gitlog-to-changelog: remove #!/usr/bin/perl in favor of more > portable... > MIME-Version: 1.0 > Content-Type: text/

Re: Explicit interpreter paths considered harmful

On 10/30/2009 04:32 PM, Jim Meyering wrote: I definitely want to keep the -w. If you're writing Perl without warnings enabled, you'd better have a very good reason, and can certainly manage the extra effort of applying s/wS/S/ to those two lines -- along with a comment justifying it, I'd expect.

Re: Explicit interpreter paths considered harmful

Paolo Bonzini wrote: > On 10/30/2009 01:38 PM, Eric Blake wrote: >> According to Jim Meyering on 10/30/2009 6:29 AM: >>> +eval '(exit $?0)'&& eval 'exec perl -wS "$0" ${1+"$@"}' >>> +& eval 'exec /usr/bin/perl -wS "$0" $argv:q' shouldn't that be perl, rather than /usr/bin/perl? ...

Re: Explicit interpreter paths considered harmful

On 10/30/2009 01:38 PM, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/30/2009 6:29 AM: +eval '(exit $?0)'&& eval 'exec perl -wS "$0" ${1+"$@"}' +& eval 'exec /usr/bin/perl -wS "$0" $argv:q' shouldn't that be perl, rather than /usr/bin/perl?

Re: Explicit interpreter paths considered harmful

Eric Blake wrote: > According to Jim Meyering on 10/30/2009 6:29 AM: >> +eval '(exit $?0)' && eval 'exec perl -wS "$0" ${1+"$@"}' >> + & eval 'exec /usr/bin/perl -wS "$0" $argv:q' >>> shouldn't that be perl, rather than /usr/bin/perl? >> >> I could not arrange for that 2nd eval line to mak

Re: stat() replacement with _LARGE_FILES on AIX

Eric Blake wrote: > According to Michael Haubenwallner on 10/30/2009 6:21 AM: >> Hi, > >> using stat() replacement on AIX results in these build errors (seen in >> gzip-1.3.13 on AIX5.3), because AIX defines 'stat' to 'stat64' when >> _LARGE_FILES is defined (by AC_SYS_LARGEFILE): > > Thanks for

Re: [PATCH] exclude: avoid an unwarranted warning

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 10/28/2009 2:42 PM: > Jim Meyering wrote: >> There are other ways to avoid the warning that are cleaner > > Yes, I would have handled this one by adding a 'default: break;' > alternative to the 'switch' statement. As a by-

Re: test-utimens.h:105: assertion failed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 10/30/2009 2:32 AM: > A (f)utimens test fail on Ubuntu 8.04 LTS: Thanks for the report. Which kernel and which version of glibc? Is it a machine I might have access to, like the gcc compile farm? > I can't reproduce

Re: Explicit interpreter paths considered harmful

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/30/2009 6:29 AM: > +eval '(exit $?0)' && eval 'exec perl -wS "$0" ${1+"$@"}' > + & eval 'exec /usr/bin/perl -wS "$0" $argv:q' >> shouldn't that be perl, rather than /usr/bin/perl? > > I could not arrange for th

Re: stat() replacement with _LARGE_FILES on AIX

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Michael Haubenwallner on 10/30/2009 6:21 AM: > Hi, > > using stat() replacement on AIX results in these build errors (seen in > gzip-1.3.13 on AIX5.3), because AIX defines 'stat' to 'stat64' when > _LARGE_FILES is defined (by AC_SYS_LARGE

Re: Explicit interpreter paths considered harmful

Eric Blake wrote: > According to Jim Meyering on 10/30/2009 6:00 AM: @@ -1,7 +1,9 @@ -#!/usr/bin/perl +eval '(exit $?0)' && eval 'exec perl -wS "$0" ${1+"$@"}' + & eval 'exec /usr/bin/perl -wS "$0" $argv:q' > > shouldn't that be perl, rather than /usr/bin/perl? I could not arr

stat() replacement with _LARGE_FILES on AIX

Hi, using stat() replacement on AIX results in these build errors (seen in gzip-1.3.13 on AIX5.3), because AIX defines 'stat' to 'stat64' when _LARGE_FILES is defined (by AC_SYS_LARGEFILE): CC lstat.o lstat.c:62: warning: "struct stat" declared inside parameter list lstat.c:63: error: confl

Re: Explicit interpreter paths considered harmful

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/30/2009 6:00 AM: >>> @@ -1,7 +1,9 @@ >>> -#!/usr/bin/perl >>> +eval '(exit $?0)' && eval 'exec perl -wS "$0" ${1+"$@"}' >>> + & eval 'exec /usr/bin/perl -wS "$0" $argv:q' shouldn't that be perl, rather than /usr/bin/pe

Re: mkstemps

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 6/30/2009 6:12 AM: > Thus, creating a temporary file with a known extension is > more common than a temporary directory with a known extension. > > At any rate, let's see whether we get any feedback from glibc: > http://sour

Re: Explicit interpreter paths considered harmful

Eric Blake wrote: > According to Jim Meyering on 10/30/2009 2:52 AM: >> FYI, this appears to work, both when invoked directly, and when invoked >> as "perl gitlog-to-changelog ...", but I'm still on the fence... >> Is it worth the ugliness, when invoking with $(PERL) is so easy, and >> when the rec

Re: Explicit interpreter paths considered harmful

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/30/2009 2:52 AM: > FYI, this appears to work, both when invoked directly, and when invoked > as "perl gitlog-to-changelog ...", but I'm still on the fence... > Is it worth the ugliness, when invoking with $(PERL) is so e

Re: mkdir vs. GPL

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/30/2009 3:05 AM: >> I think the only clean solution is to bite the bullet and decide that >> canonicalize-lgpl is the only module which can provide >> canonicalize_file_name, >> which in turn means that coreutils needs

Re: mkdir vs. GPL

Eric Blake wrote: > Jim Meyering meyering.net> writes: > >> > [3/5] dirname-lgpl: adjust clients that don't need full dirname >> > Fallout from the split. In particular, test-mkdir and test-rename no >> > longer >> > need libintl. Meanwhile, openat and friends no longer drag in dirname,

Re: Explicit interpreter paths considered harmful

Ludovic Courtès wrote: > k...@freefriends.org (Karl Berry) writes: > >> -#!/usr/bin/perl >> +#!/bin/sh >> >> Just to mention that an alternative would be #!/usr/bin/env perl. > > It won’t work on NixOS, which doesn’t have /usr/bin. (On NixOS, the > only “standard” path that can be relied o

test-utimens.h:105: assertion failed

A (f)utimens test fail on Ubuntu 8.04 LTS: ../../gltests/test-utimens.h:105: assertion failed FAIL: test-fdutimensat ../../gltests/test-futimens.h:109: assertion failed FAIL: test-futimens ../../gltests/test-utimens.h:105: assertion failed FAIL: test-utimens Reproduce with: gnulib-tool --test --

Re: Explicit interpreter paths considered harmful

Ludovic Courtès wrote: ... > because perl eventually execs /bin/sh: > > 4473 execve("./build-aux/gitlog-to-changelog", > ["./build-aux/gitlog-to-changelog"], [/* 60 vars */]) = 0 > 4473 execve("/var/run/current-system/sw/bin/perl", ["perl", "-S", > "./build-aux/gitlog-to-changelog"], [/* 59 var

Re: Explicit interpreter paths considered harmful

l...@gnu.org (Ludovic Courtès) writes: > Here's a patch. > > Likewise, ‘pmccabe2html’ assumes /usr/bin/awk, but I’m not sure what to > do here: See the documentation in pmccabe2html -- the recommended way to use the script is already using $(AWK). So I don't think there is any problem, is there?