RE: alloca in HP NonStop

> From: Paul Eggert [mailto:egg...@cs.ucla.edu] > Sent: Tuesday, July 03, 2012 2:38 AM > To: Joachim Schmitz > Cc: bug-gnulib@gnu.org > Subject: Re: alloca in HP NonStop > > On 06/28/2012 09:41 AM, Joachim Schmitz wrote: > > Or drop it an just take the else branch. > > Yes, that sounds simpler. A

Re: AC_DEFUN_ONCE and conditional dependencies

On 07/02/2012 07:20 PM, Bruno Haible wrote: > Hi Eric, > > How can we fix this? > > I'm thinking about two macros AC_DEFUN_ONCE_IFNEEDED, AC_REQUIRE_IFNEEDED Again, avoiding the AC_ namespace unless Autoconf 2.80 adds this methods might be wise, we'd be safer with the names gl_DEFUN_ONCE_IFNEED

Re: AC_DEFUN_ONCE and maintainability

On 07/02/2012 07:22 PM, Bruno Haible wrote: > Hi Paul, > >> How about the name AC_DEF_ONCE instead? > > Yes, this name is equally good, possibly better than AC_ONCE. Technically, the AC_ namespace is reserved for autoconf, and introducing a new AC_ name (whether AC_ONCE or AC_DEF_ONCE) in gnulib

Re: AC_DEFUN_ONCE and maintainability

Hi Paul, > How about the name AC_DEF_ONCE instead? Yes, this name is equally good, possibly better than AC_ONCE. Thanks. Bruno

AC_DEFUN_ONCE and conditional dependencies

Hi Eric, I wrote: > But I have two issues with AC_DEFUN_ONCE. > ... > More generally, this would lead to the coding convention that all macros > gl_FUNC_FOO for a single function foo() would be an AC_DEFUN_ONCE. My second issue with AC_DEFUN_ONCE is that this coding convention would defeat parts

Re: AC_DEFUN_ONCE and maintainability

On 07/02/2012 06:08 PM, Bruno Haible wrote: > About the naming: The macro FOO in case (C) cannot take arguments and > cannot be invoked; it is far from a "function" - and 'defun' in Lisp > is meant to define a function. Thanks for your careful analysis. I worry that the name AC_ONCE is a bit cryp

AC_DEFUN_ONCE and maintainability

Hi Eric, > The canonical > fix in gnulib is to use AC_DEFUN_ONCE instead of AC_DEFUN for any > function that we want to guarantee that it gets expanded without > triggering the older autoconf bug. You're right; I should revert the patch and use AC_DEFUN_ONCE([gl_FUNC_LOG],...) instead. But I hav

Re: alloca in HP NonStop

On 06/28/2012 09:41 AM, Joachim Schmitz wrote: > Or drop it an just take the else branch. Yes, that sounds simpler. Also, how about the following ideas for simplification: Don't bother checking __TANDEM; _TNS_E_TARGET should suffice. This fixes what appears to be a bug on older Tandem systems.

Re: [musl] Re: musl bugs found through gnulib

On 06/20/2012 05:04 AM, Rich Felker wrote: > Some more updates.. > > On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: >> When I compile all of gnulib, I also get a compilation error >> (may be a musl or a gnulib problem, haven't investigated): >> fsusage.c: In function 'get_fs_usage':

Re: fsusage.c fails to build on GNU

Pádraig Brady wrote: > OK I'll post a follow up patch. Please consider also the analysis for systems with Linux but without glibc, done by Rich Felker here: Br

Re: fsusage.c fails to build on GNU

On 07/02/2012 11:35 PM, Paul Eggert wrote: > On 07/02/2012 02:25 PM, Pádraig Brady wrote: >> I think the following might be a better fix >> since it will remove redundant code in this case. > > Yes, that sounds like a win. Before I got your message, > though, I had already installed the following

Re: fsusage.c fails to build on GNU

On 07/02/2012 02:35 PM, Paul Eggert wrote: > Before I got your message, > though, I had already installed the following more-conservative > patch Sorry, forgot the patch. Here it is: >From defe57376249c1385b2874b43307e4c686a1d38c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 2 Jul 2012

Re: fsusage.c fails to build on GNU

On 07/02/2012 02:25 PM, Pádraig Brady wrote: > I think the following might be a better fix > since it will remove redundant code in this case. Yes, that sounds like a win. Before I got your message, though, I had already installed the following more-conservative patch, as I thought I had introduc

[PATCH] fsusage: avoid needless check on GNU/Linux

I installed this as an obvious minor tuneup. * m4/fsusage.m4 (gl_FILE_SYSTEM_USAGE): Omit STAT_STATFS3_OSF1 check on GNU/Linux systems, since it can't possibly work. --- ChangeLog |6 ++ m4/fsusage.m4 | 53 +++-- 2 files changed, 33 in

Re: fsusage.c fails to build on GNU

On 07/02/2012 10:28 PM, Jim Meyering wrote: > Ludovic Courtès wrote: >> On GNU/Hurd, ‘struct statfs’ is defined in . However, >> fsusage.c ends up including only , and thus, ‘struct >> statfs’ and the ‘statfs’ function aren’t defined/declared, leading to: >> >> fsusage.c: In function 'get_fs_usa

Re: fsusage.c fails to build on GNU

Ludovic Courtès wrote: > On GNU/Hurd, ‘struct statfs’ is defined in . However, > fsusage.c ends up including only , and thus, ‘struct > statfs’ and the ‘statfs’ function aren’t defined/declared, leading to: > > fsusage.c: In function 'get_fs_usage': > fsusage.c:222:17: error: storage size of '

fsusage.c fails to build on GNU

Hello, On GNU/Hurd, ‘struct statfs’ is defined in . However, fsusage.c ends up including only , and thus, ‘struct statfs’ and the ‘statfs’ function aren’t defined/declared, leading to: fsusage.c: In function 'get_fs_usage': fsusage.c:222:17: error: storage size of 'fsd' isn't known fsusage

Re: canonicalize_file_name does not support MS-Windows style file names

> Date: Tue, 19 Jun 2012 18:55:02 +0300 > From: Eli Zaretskii > CC: bug-gnulib@gnu.org > > > Date: Tue, 17 Jan 2012 22:04:38 +0200 > > From: Eli Zaretskii > > CC: bug-gnulib@gnu.org > > > > > From: Bruno Haible > > > Bcc: br...@haible.de > > > Date: Tue, 17 Jan 2012 20:07:11 +0100 > > > > > >

Re: minimum autoconf version

On 07/01/2012 05:40 PM, Bruno Haible wrote: > Hi all, > > > The problem occurs only with Autoconf versions < 2.64. Carlos used > version 2.63. In the testdir's configure file generated, there are > the following lines: > > So, there are two copies of gl_FUNC_LOGF in the expansion. In Autoconf

Re: minimum autoconf version

Paul Eggert wrote: > On 07/01/2012 04:40 PM, Bruno Haible wrote: >> I would therefore propose (b), that is, to bump the required Autoconf >> version in the DEPENDENCIES file and gnulib-tool to 2.64. > > Given your description of the hassles involved in supporting > older Autoconf versions, this see

Re: minimum autoconf version

On 07/01/2012 04:40 PM, Bruno Haible wrote: > I would therefore propose (b), that is, to bump the required Autoconf > version in the DEPENDENCIES file and gnulib-tool to 2.64. Given your description of the hassles involved in supporting older Autoconf versions, this seems like the better way to go