Re: bug#8675: error: token "@" is not valid in preprocessor expressions

On 5/18/2011 6:27 PM, Bruno Haible wrote: So, if the reporter was using GNU make and the previous Makefile.in was based on gnulib 2011-04-03 or newer and the reporter did a make command in the top-level directory that recreated config.status before recursing into lib/ and then

Re: perror bug

On 2011-14-03 I wrote in : > With gnulib, there are three problems > in toto: >   1) The strerror_r replacement, when EXTEND_STRERROR_R is defined, >      clobbers the strerror function's buffer, which it shouldn't. >   2) The perr

Re: proposed new module intprops-test

Hi Paul, > > ./gnulib-tool --with-tests --test intprops > > Thanks, I ran that and it worked. It fails to compile on HP-UX 11.23 and 11.31 with cc, on IRIX 6.5 with cc, on OSF/1 5.1 with cc, and on Solaris 9 and 10 (SPARC) with cc. Here are the error messages on HP-UX 11.23 with cc: cc

Re: error: token "@" is not valid in preprocessor expressions

Hi Paul, > all we need to do is to have unistd.h > depend on Makefile. And, once unistd.h depends on Makefile > then it need not depend on config.status (as Makefile already > depends on config.status). Like this: > > --- a/modules/unistd > +++ b/modules/unistd > @@ -20,7 +20,7 @@ BUILT_SOURCES

Re: error: token "@" is not valid in preprocessor expressions

On 05/18/11 13:35, Andreas Schwab wrote: > Normally, if GNU make sees that a > makefile is remade it rereads it automatically. Ah, thanks, I didn't know that. So if we care only about GNU make, then all we need to do is to have unistd.h depend on Makefile. And, once unistd.h depends on Makefile

Re: error: token "@" is not valid in preprocessor expressions

Paul Eggert writes: > I don't see how adding a dependency would fix this problem. In this > case, lib/Makefile in turn depended on 'configure', 'configure.in', > 'm4/longlong.m4', etc., etc., and one of these files got updated, so > lib/Makefile was regenerated; but as I understand it, the 'make

Re: error: token "@" is not valid in preprocessor expressions

[Adding bug-gnulib to this thread. For bug-gnulib readers, the scenario is in Emacs a "bzr update; make" failed with: ./unistd.h:1186:5: error: token "@" is not valid in preprocessor expressions because unistd.h was built with the old Makefile. Full thread at

[PATCH] fnmatch: avoid compiler warning

Detected on Ubuntu 10.04, where the glibc fnmatch fix is not yet present; also reproduced via: $ gl_cv_func_fnmatch_posix=no CFLAGS=-Wall \ ./gnulib-tool --with-tests --test fnmatch In file included from gllib/fnmatch.c:172:0: gllib/fnmatch_loop.c: In function ‘internal_fnmatch’: gllib/fnmatch

Re: [libvirt] [PATCH] Ensure virStrerror always sets an error string

On Wed, May 18, 2011 at 11:27:28AM -0600, Eric Blake wrote: > [adding bug-gnulib] > > On 05/18/2011 11:07 AM, Daniel P. Berrange wrote: > > strerror_r() is free to not set any error string, if the passed > > errno is not valid. It may, however, still return a pointer to > > the original passed in

Re: [libvirt] [PATCH] Ensure virStrerror always sets an error string

[adding bug-gnulib] On 05/18/2011 11:07 AM, Daniel P. Berrange wrote: > strerror_r() is free to not set any error string, if the passed > errno is not valid. It may, however, still return a pointer to > the original passed in buffer. This resulting in random garbage > from the stack being present

Re: socketless platforms?

On 05/18/2011 10:18 AM, Sam Steingold wrote: > is there such a thing as a platform without socket support? > if yes, how do I detect that after I call gl_SOCKETLIB? Not all platforms support Unix sockets (AF_UNIX/AF_LOCAL is lacking on mingw) or IPv6 sockets (AF_INET6 is lacking on various platfor

socketless platforms?

is there such a thing as a platform without socket support? if yes, how do I detect that after I call gl_SOCKETLIB? -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://www.memritv.org http://openvotingconsortium.org http://pmw.org.il http://honestreporti

GNULIB_PORTCHECK

what does GNULIB_PORTCHECK mean? e.g., ./config.log:REPLACE_TIMEGM='GNULIB_PORTCHECK' the only mention I see is time_h.m4: dnl If another module says to replace or to not replace, do that. dnl Otherwise, replace only if someone compiles with -DGNULIB_PORTCHECK; dnl this lets maintainers check

Re: include without check

On 05/18/2011 09:18 AM, Eric Blake wrote: > On 05/18/2011 07:37 AM, Sam Steingold wrote: >> sys_uio.in.h includes without #ifdef HAVE_SYS_TYPES_H. >> can this file be assumed to be present on all platforms including mingw? > > gnulib/doc/posix-headers/sys_types.texi does not list any platform whe

Re: include without check

On 05/18/2011 07:37 AM, Sam Steingold wrote: > sys_uio.in.h includes without #ifdef HAVE_SYS_TYPES_H. > can this file be assumed to be present on all platforms including mingw? gnulib/doc/posix-headers/sys_types.texi does not list any platform where it is missing. Yes, you can assume this file i

include without check

sys_uio.in.h includes without #ifdef HAVE_SYS_TYPES_H. can this file be assumed to be present on all platforms including mingw? -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://palestinefacts.org http://mideasttruth.com http://pmw.org.il http://hones

[PATCH] maint.mk: three new prohibit__without_use rules

FYI, three more prohibit__without_use rules: >From 2c25c9ebe8db1415bfde25f0a451767332c8cf59 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 13 May 2011 23:35:48 +0200 Subject: [PATCH] maint.mk: three new prohibit__without_use rules * top/maint.mk (sc_prohibit_stdio--_without_use): New rul

Re: [PATCH] maint.mk: add a syntax-check rule to ensure tightly-scoped symbols

Pádraig Brady wrote: > On 17/05/11 15:23, Pádraig Brady wrote: >> Given '^__.*' names are reserved by the compiler, >> perhaps the happy medium is to to allow single underscores, >> but exclude double underscores, with something like: > > I'm going with the following, so as to not put the > onus on