Re: bug#5999: new snapshot available: coreutils-8.4.100-81926

Bruno Haible wrote: > Paolo Bonzini wrote: >> > Here's a patch to make that diagnostic go where it belongs >> > for all gnulib-using projects: >> >> I wonder if we shouldn't do that for all _autoconf_-using projects! > > Or, at least, for all tests in all gnulib-using projects. There are > more pos

Re: bug#5999: new snapshot available: coreutils-8.4.100-81926

Gilles Espinasse wrote: ... > I understand there is a problem but I am unsure of the direction to go. > I made this stupid patch (attached) that include the same test than > gl_cv_func_printf_directive_n in coreutils sleep usage You should be able to consider this resolved. Once you start using t

Re: [PATCH 3/2] open_memstream: port to more systems

Eric Blake wrote: > Provide brute-force implementation that works on all remaining > systems. Some day, it would be nice to override all APIs that > take FILE*, so that we can guarantee efficient in-memory access, > but in the meantime, this works even if it is slow on deficient > platforms. The

tmpfile-gnu: yes!

Eric Blake wrote: ... > This is a proof-of-concept patch; it solves the problem at hand, > but has some dependencies on incompatible modules that would > need to be relaxed to LGPLv2+ before this module could be used > in libvirt. > ... > Do we want a tmpfile-gnu module that guarantees that tmpfile

[PATCH] maint.mk: syntax-check: prohibit HAVE__H that are always true

I've just pushed the patch below. It exposed a few unnecessary #if tests in coreutils: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=2191fe8f8d84e3 Initially I planned to have one rule per checked header, in order to give diagnostics saying precisely what HAVE_HEADER_H symbols is

Re: [PATCH] maint.mk: syntax-check: prohibit HAVE__H that are always true

On 27/04/10 13:15, Jim Meyering wrote: > I've just pushed the patch below. > It exposed a few unnecessary #if tests in coreutils: Very nice check. > Hence the compromise of searching for all of them at once, > with the downside that occasionally you'll be warned about > a line like this one (from

Re: [PATCH] maint.mk: syntax-check: prohibit HAVE__H that are always true

Pádraig Brady wrote: > On 27/04/10 13:15, Jim Meyering wrote: >> I've just pushed the patch below. >> It exposed a few unnecessary #if tests in coreutils: > > Very nice check. Thanks. >> Hence the compromise of searching for all of them at once, >> with the downside that occasionally you'll be wa

Re: [libvirt] [PATCH] maint: update to latest gnulib

Eric Blake wrote: > * cfg.mk (gnulib_dir): Override default in maint.mk. > * .gnulib: Update to latest. > Reported by Jim Meyering. > --- > > Update to the latest gnulib for some portability fixes. Thankfully, > we already pass all of the new syntax checks, but Jim did note (on > the gnulib list)

replacement header licenses

The following replacement headers are all under LGPL instead of LGPLv2+ licensing. Any objection to relaxing them, so that projects like libvirt can use all the replacement headers for things like GNULIB_POSIXCHECK or passing Jim's recent maint.mk syntax check? fcntl-h getopt-posix inttypes local

[PATCH 1/2] pthread: mention library for linking

* modules/pthread (Link): Mention $(LIB_PTHREAD). Signed-off-by: Eric Blake --- I noticed this while trying to remove uses of HAVE_PTHREAD_H from libvirt. ChangeLog |5 + modules/pthread |3 +++ 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/Change

[PATCH 2/2] full-read, full-write: relax license

Jim Meyering gave consent to this action: http://lists.gnu.org/archive/html/bug-gnulib/2010-04/msg00446.html * modules/full-read (License): Drop to LGPLv2+. * modules/full-write (License): Likewise. * modules/safe-read (License): Likewise. * modules/safe-write (License): Likewise. Signed-off-by:

Re: [PATCH] ftruncate: mark module as obsolete; even MinGW provides it, now

On 9-Apr-2010, Paolo Bonzini wrote: | On 04/09/2010 11:04 AM, Bruno Haible wrote: | > Indeed. But since mingw has it but MSVC doesn't, this raises the | > question: how important is the MSVC porting platform (use Microsoft's | > compiler and include files [proprietary but downloadable at zero cos

[PATCH 0/4] A few portability fixes

Hello, here are a few fixes for getting rid of warnings on Solaris and Tru64: the first three are just for avoiding warnings; the last one is an actual bug fix. Thanks, Andreas Andreas Gruenbacher (4): Avoid an 'empty declaration' / 'extraneous semicolon' warning Avoid an utimes(2) warning

[PATCH 2/4] Avoid an utimes(2) warning

* lib/utimens.c: On some systems, the timestamp parameter of utimens(2) is not declared as a const *; avoid warnings in that case. Signed-off-by: Andreas Gruenbacher --- ChangeLog |3 +++ lib/utimens.c |4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/ChangeLog

[PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

* m4/bison.m4 (gl_BISON): We need to use AM_MISSING_PROG for making bison the default YACC or else packages cannot be built without bison. Signed-off-by: Andreas Gruenbacher --- ChangeLog |3 +++ m4/bison.m4 |4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/Change

[PATCH 1/4] Avoid an 'empty declaration' / 'extraneous semicolon' warning

* lib/canonicalize-lgpl.c: Avoid an 'empty declaration' / 'extraneous semicolon' warning with some compilers. Signed-off-by: Andreas Gruenbacher --- ChangeLog |5 + lib/canonicalize-lgpl.c |2 ++ 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/ChangeLog b

[PATCH 3/4] Avoid a stupid 'const object should have initializer' warning

* lib/getdate.y (RELATIVE_TIME_0): Avoid a stupid 'const object should have initializer' warning. Signed-off-by: Andreas Gruenbacher --- ChangeLog |3 +++ lib/getdate.y |2 +- 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6743cce..3ed5687

Re: [PATCH 1/4] Avoid an 'empty declaration' / 'extraneous semicolon' warning

On 04/27/2010 03:23 PM, Andreas Gruenbacher wrote: > * lib/canonicalize-lgpl.c: Avoid an 'empty declaration' / 'extraneous > semicolon' warning with some compilers. > Do you have commit rights to gnulib yet? > diff --git a/lib/canonicalize-lgpl.c b/lib/canonicalize-lgpl.c > index 480a132..d98b3a

Re: [PATCH 2/4] Avoid an utimes(2) warning

On 04/27/2010 03:23 PM, Andreas Gruenbacher wrote: > * lib/utimens.c: On some systems, the timestamp parameter of > utimens(2) is not declared as a const *; avoid warnings in that case. utimes(2), not utimens(2). Which system(s)? At any rate, since we (intentionally) don't provide a gnulib repla

Re: [PATCH 3/4] Avoid a stupid 'const object should have initializer' warning

On 04/27/2010 03:24 PM, Andreas Gruenbacher wrote: > * lib/getdate.y (RELATIVE_TIME_0): Avoid a stupid 'const object should > have initializer' warning. > > @@ -152,7 +152,7 @@ typedef struct > #if HAVE_COMPOUND_LITERALS > # define RELATIVE_TIME_0 ((relative_time) { 0, 0, 0, 0, 0, 0, 0 }) > #el

Re: [PATCH 2/4] Avoid an utimes(2) warning

Hi Andreas, > * lib/utimens.c: On some systems, the timestamp parameter of > utimens(2) is not declared as a const *; avoid warnings in that case. You mean the parameter of futimesat(), futimes(), lutimes()? And which platform is affected? I just checked futimesat() on Solaris and futimes(), luti

Re: [PATCH 3/4] Avoid a stupid 'const object should have initializer' warning

Andreas Gruenbacher wrote: > diff --git a/lib/getdate.y b/lib/getdate.y > index 445865b..dcfe3cc 100644 > --- a/lib/getdate.y > +++ b/lib/getdate.y > @@ -152,7 +152,7 @@ typedef struct > #if HAVE_COMPOUND_LITERALS > # define RELATIVE_TIME_0 ((relative_time) { 0, 0, 0, 0, 0, 0, 0 }) > #else > -st

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

Hi Andreas, > * m4/bison.m4 (gl_BISON): We need to use AM_MISSING_PROG for making > bison the default YACC or else packages cannot be built without bison. ># getdate.y works with bison only. > - : ${YACC='bison -y'} Can you explain what is the problem with YACC='bison -y'? This variable will

Re: [PATCH 2/4] Avoid an utimes(2) warning

On Tuesday 27 April 2010 23:41:08 Eric Blake wrote: > On 04/27/2010 03:23 PM, Andreas Gruenbacher wrote: > > * lib/utimens.c: On some systems, the timestamp parameter of > > utimens(2) is not declared as a const *; avoid warnings in that case. > > utimes(2), not utimens(2). Oops, yes. > Which sy

Re: [PATCH 3/4] Avoid a stupid 'const object should have initializer' warning

On Tuesday 27 April 2010 23:42:07 Eric Blake wrote: > On 04/27/2010 03:24 PM, Andreas Gruenbacher wrote: > > * lib/getdate.y (RELATIVE_TIME_0): Avoid a stupid 'const object should > > have initializer' warning. > > > > @@ -152,7 +152,7 @@ typedef struct > > #if HAVE_COMPOUND_LITERALS > > # define

Re: [PATCH 2/4] Avoid an utimes(2) warning

On Tuesday 27 April 2010 23:56:34 Bruno Haible wrote: > Hi Andreas, > > > * lib/utimens.c: On some systems, the timestamp parameter of > > utimens(2) is not declared as a const *; avoid warnings in that case. > > You mean the parameter of futimesat(), futimes(), lutimes()? I know that utimes() i

Re: [PATCH 3/4] Avoid a stupid 'const object should have initializer' warning

On Wednesday 28 April 2010 00:00:35 Bruno Haible wrote: > Andreas Gruenbacher wrote: > > diff --git a/lib/getdate.y b/lib/getdate.y > > index 445865b..dcfe3cc 100644 > > --- a/lib/getdate.y > > +++ b/lib/getdate.y > > @@ -152,7 +152,7 @@ typedef struct > > #if HAVE_COMPOUND_LITERALS > > # define

Re: on msvc

Hi John, > | > this platforms lacks > | > , opendir, readdir, but we have not had a single request > | > for supporting this in gnulib in 7 years. > | > | dirent functions are actually not _that_ much used. > > Sorry for jumping in late to this thread... > > Octave, which attempts to be buildab

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

On Wednesday 28 April 2010 00:15:59 Bruno Haible wrote: > Hi Andreas, > > > * m4/bison.m4 (gl_BISON): We need to use AM_MISSING_PROG for making > > bison the default YACC or else packages cannot be built without bison. > ># getdate.y works with bison only. > > - : ${YACC='bison -y'} > > Can

Re: [PATCH 1/4] Avoid an 'empty declaration' / 'extraneous semicolon' warning

On Tuesday 27 April 2010 23:38:47 Eric Blake wrote: > Do you have commit rights to gnulib yet? No ... and judging from how things went the last time, getting the additional paperwork done would probably take months on our end :) Andreas

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

On Wed, 2010 Apr 28 00:40+0200, Andreas Gruenbacher wrote: > > ... unless the timestamps get destroyed, or make gets things wrong. > The latter apparently happened to Daniel (CCed) on Tru64 with the > native make; the result was a build failure. (GNU make got that > situation right.) I would have

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

Andreas Gruenbacher wrote: > > This variable will not be used if a user unpacks and compiles a virgin > > tarball. > > ... unless the timestamps get destroyed, or make gets things wrong. The > latter apparently happened to Daniel (CCed) on Tru64 with the native make; > the > result was a build

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

On Wed, 2010 Apr 28 01:23+0200, Bruno Haible wrote: > > OK, so that was the original problem. I agree it's a nasty one. > > One approach is described in the autoconf documentation > > This approach looks reasonable. Yo

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

Daniel Richard G. wrote: > Timestamps were not the problem. The native make(1) worked fine (i.e. > did not try to invoke $(YACC)) when building inside the source tree. and: > For my part, if I've fiddled with a .y file, and $(YACC) doesn't work, > then a build failure is a given. The problem here

Re: [PATCH 2/4] Avoid an utimes(2) warning

Andreas Gruenbacher wrote: > > > * lib/utimens.c: On some systems, the timestamp parameter of > > > utimens(2) is not declared as a const *; avoid warnings in that case. > > > > You mean the parameter of futimesat(), futimes(), lutimes()? > > I know that utimes() is affected. Aha! Now we're at t

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

On Wed, 2010 Apr 28 02:05+0200, Bruno Haible wrote: > > If you can build a package with non-GNU make in builddir = srcdir, and > with GNU make in builddir != srcdir, that's all we promise. Considering all the trouble Automake goes to to accommodate less-capable make(1) programs, that's a bit disap

Re: on msvc

On 28-Apr-2010, Bruno Haible wrote: | The way to do that is that you provide a good implementation of said | functions opendir, readdir, and closedir. Sure, I understand that. Sorry if my earlier message sounded like I was expecting someone else to do this part. | Projects that use gnulib have

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here

Hello, * Bruno Haible wrote on Wed, Apr 28, 2010 at 01:23:18AM CEST: > Andreas Gruenbacher wrote: > > > This variable will not be used if a user unpacks and compiles a virgin > > > tarball. > > > > ... unless the timestamps get destroyed, or make gets things wrong. The > > latter apparently hap