Re: Autoconf-2.68b possible patch for FreeBSD, MacOS X

On 03/06/2012 11:52 PM, P. Martin wrote: > I fail nearly all the > tests now after about 270 on OSX Lion. Please lmk if you want > some test dirs. Sure, some test output would be helpful.

Re: [GNU Autoconf 2.68] testsuite: 1 10 11 12 14 16 17 20 22 24 25 27 28 32 33 36 38 208 211 212 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 231 232 233 234 235 236 237 238 239 240

On 03/06/2012 11:54 PM, Martin & Dunja Zaun wrote: > The failures should be easily reproducible on a vanilla Solaris 11/x86_64. Thanks, I guess someone with easy access to an installation of that OS will have to dive in a bit more.

Re: Autoconf-2.68b possible patch for FreeBSD, MacOS X

mplains 'Regular expression too big' for a 938-byte regular expression in the test. I hope the following further patch, which is clearly needed anyway and which I just now pushed, fixes the remaining problems. >From 0f133bbea81a9e3cea1278577f498d617b89c5d8 Mon Sep 17 00:00:00 2001 From:

Re: AC_INCLUDES_DEFAULT does not need to probe for headers that are part of C89 or POSIX.1 anymore

No doubt the set of default headers should be modernized, but it's going too far, I expect, to have Autoconf assumes that headers like exist. Autoconf-generated scripts are sometimes used to configure on MSVC platforms, for example, and MSVC doesn't have .

Re: AC_INCLUDES_DEFAULT does not need to probe for headers that are part of C89 or POSIX.1 anymore

On 04/04/2012 07:59 PM, Zack Weinberg wrote: > m4_pushdef([AC_INCLUDES_DEFAULT], [$1]) > > and some sort of officially-supported way to do that would make me happy. I agree that the current situation is not good; perhaps we should just document the above workaround? Whatever solution we eventuall

Re: Removal of double check from AC_CHECK_HEADER (was Re: AC_INCLUDES_DEFAULT does not need to probe...)

On 04/12/2012 09:59 AM, Zack Weinberg wrote: > I meant to ask: is there a planned schedule for getting rid of the > "mongrel" double check that AC_CHECK_HEADER[S] does if you don't > supply a fourth argument? Not as far as I know. There isn't that much active development right now.

Re: [bug-gzip] gzip-1.5 test failures on FreeBSD 9.0 and NetBSD 5.1

On 06/20/2012 07:16 AM, Eric Blake wrote: > do we know which shells suffer from this > POSIX non-compliance bug, and whether they are still in active use Sorry, I don't know of a list of such shells. The problem is documented in the Autoconf manual, without listing shells. I have verified that th

Re: Autoconf should allow the developer to require a POSIX shell

On 06/28/2012 04:18 PM, Stefano Lattarini wrote: > WDYT? Is this something worth pursuing for Autoconf 2.70? I think so. As recently as Solaris 8 this approach had trouble since the POSIXish shells were optional and often were not installed. However, starting in Solaris 9 /usr/xpg4/bin/sh has b

Re: [PATCH] m4sh: avoid // issues in _AS_PATH_WALK

That patch looks good to me, and thanks.

Re: AC_CHECK_ALIGNOF cross-compile detection fails with newer gcc and offsetof fallback

re. I pushed the following. >From 91cd3fb1ea64567b40d9a55b94074e198dae964b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 6 Sep 2012 14:50:27 -0700 Subject: [PATCH] AC_CHECK_ALIGNOF: fix cross-compilation bug with newer gcc * doc/autoconf.texi (Default Includes, Particular Fu

Re: AC_PROG_CC_* shouldn't append multiple options

899 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 20 Sep 2012 14:32:06 -0700 Subject: [PATCH] AC_PROG_CC_STDC: fold into AC_PROG_CC, removing C11 macro * NEWS: * doc/autoconf.texi (C Compiler): Document the following. * lib/autoconf/c.m4 (AC_PROG_CC): Check for the latest C version suppor

Re: AC_PROG_CC_* shouldn't append multiple options

On 09/20/2012 03:29 PM, Adrian Bunk wrote: > ac_cv_prog_cc_c11 is no longer documented (but still set, and should > not be removed). Wanting to check that variable might even be a valid > usecase for AC_PROG_CC_C11? I'm not sure we should be documenting any of that stuff, but if we do, I'd rathe

Re: [PATCH] AC_PROG_CC_C11: new macro, which AC_PROG_CC_STDC now defaults to

possible mode in AC_PROG_CC makes sense. Yes, on further thought I'm inclined to agree. Also, it's a lot simpler. Also, it fixes Jim's bug. There's a lot to like. Please see the patch below, which I've pushed. Further comments welcome. >From f7fe375b26f39d0a6624a

Re: Documentation and AC_DEFINE/AC_DEFINE_UNQUOTED

On 09/22/2012 04:38 AM, Brad Smith wrote: > AC_DEFINE([FOO]) > > and yet autoconf pukes on this. I had no problem with that line, with Autoconf 2.68. Can you supply more details about how to reproduce your problem?

Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

Sorry, I don't see a bug there. "gcc -std=gnu99" accepts ISO C11, in the sense that it passes all the C11 tests that we have, if your version of GCC is sufficiently new. This is because the GCC supports these C11 features even when running in C99 mode. If there's some C11 feature that is missing

Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

On 09/25/2012 02:22 PM, Adrian Bunk wrote: > #if !defined(__STDC_VERSION__) || (__STDC_VERSION__ < 201112L) If that's what the user wants, they have that already; they don't need Autoconf for it. Surely it's more useful if Autoconf tests for actual features rather than testing __STDC_VERSION__.

Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

On 09/25/2012 05:04 PM, Adrian Bunk wrote: > If a future gcc version > ... > supports C11 features in gnu11 mode it doesn't support in > gnu99 mode (likely) I don't see this as likely, as I don't see any such features on the horizon. (I am excluding gets, which we don't want to be encouraging any

Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

e, but I just now pushed this for IBM XL C. And it will come in the other compilers. >From 97e027a8f736c9754212607cb01f87a5997699b0 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 26 Sep 2012 07:49:59 -0700 Subject: [PATCH] AC_PROG_CC: try -qlanglvl=extc1x, for IBM XL C V12.1 * lib/autoconf/c.m4 (_AC_PROG_CC_C11): Add -qlan

Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

>> C11 is not incompatible with C99, the way that C99 was incompatible with C89. > > That sounds like a description why the autoconf 2.70 change of putting > the compiler into the highest possible mode in AC_PROG_CC could break > existing software? This doesn't sound likely either. There are v

Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

On 09/27/2012 07:29 AM, Adrian Bunk wrote: > glibc 2.16 has the following protected by what boils down to > #if defined _GNU_SOURCE || defined _ISOC11_SOURCE || \ > (defined __STDC_VERSION__ && __STDC_VERSION__ >= 201112L) > > - timespec_get() and TIME_UTC > - aligned_alloc() > - at_quick_

Re: [sr #108144] ./configure could recommend packages to install through local package manager

On 09/27/2012 12:18 PM, Eric Blake wrote: > your request sounds > something more like what pkg-config would be able to do than autoconf proper I like the idea of autoconf-generated scripts using pkg-config to find out what compiler and linker options to use. That's not what the requester asked fo

Re: [sr #108144] ./configure could recommend packages to install through local package manager

On 09/27/2012 01:32 PM, Adrian Bunk wrote: > What emacs 24.2 has is an own copy (why?) of the PKG_CHECK_MODULES macro > that is shipped as part of pkg-config, and that is today the de-facto > standard for library detection and library specific LIBS and CFLAGS > setting in open source software. I

Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

On 09/27/2012 10:04 AM, Adrian Bunk wrote: > I merely wanted to point out that there can be a difference in what > glibc provides when we end up with gnu99 instead of gnu11. Yes. And programs using Autoconf will surely prefer the gnu11 version, which is why defaulting to gnu11 is a win. > AC_PR

Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

h with IBM XL C V12.1 that you noted earlier. >From bccf4b98eebc09f4f8c77bfe4bafef41cc05e540 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 28 Sep 2012 10:44:16 -0700 Subject: [PATCH] AC_PROG_CC: clarify documentation, encourage -qlanglvl=extc1x * doc/autoconf.texi (C Compiler): Doc

Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

On 10/01/2012 02:37 PM, Adrian Bunk wrote: > Now we have two compilers that will stay in C99 mode instead of C11 mode > if they are in C99 mode by default. Sorry, I don' follow. GCC and IBM XL C will both switch to C11 mode, with the current autoconf git.

Re: bug: "gcc -std=gnu99" passes AC_PROG_CC_C11

On 10/01/2012 03:20 PM, Adrian Bunk wrote: > Not if they are set to default to C99 mode. Ah. True. That may be a problem for future versions of these two compilers, though it's not a problem for current versions. To some extent, when we're talking about future software, we're at the mercy of th

Re: [GNU Autoconf 2.69.38-b038] testsuite: 299 300 302 failed

27;s what I pushed: >From d5c68de6790c7ea50fc13f32b9f4e86737c99286 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 16 Oct 2012 13:20:58 -0700 Subject: [PATCH 1/2] AC_PROG_CC: define via AC_DEFUN_ONCE Suggested by Adrian Bunk in http://lists.gnu.org/archive/html/autoconf-patches/2012-09/msg000

Re: [GNU Autoconf 2.69] testsuite: 264 271 286 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 failed

On 11/09/2012 11:11 PM, Dennis Clarke wrote: > a pile of them are Fortran related .. probably because I don't have GNU > gfortran installed. Yup, that's a problem. At some point it'd be nice if someone coded up something that recognized that one can't do Fortran tests on platforms that lack For

[sr #108182] [doc] Clarification for behaviour of AC_CHECK_FILES

t;From 8d2596f8ea7f1ae8056efe9c033054aec2ccab54 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 17 Nov 2012 11:06:05 -0800 Subject: [PATCH] AC_CHECK_FILES: improve documentation * doc/autoconf.texi (Files): Document AC_CHECK_FILES better. Reported by Christophe Curis in <http://savannah.gnu.org/support/?108182&g

Re: AC_PROG_CC_C99 fails when configure with CFLAGS="-Werror -Wall"

Thanks, it doesn't hurt to squash those warnings so I installed the following (slightly different) patch. >From 1ee5bc84f36b90fe4d95ba630c0840525cc33991 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 10 Dec 2012 10:06:10 -0800 Subject: [PATCH] AC_PROG_CC_C99: avoid unused-var

Re: Cleaning up AC_PROG_CC_C_O semantics

On 01/14/13 02:24, Stefano Lattarini wrote: > Autoconfers, WDYT? I think I'm lost. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378 is a long thread.

Re: Cleaning up AC_PROG_CC_C_O semantics

On 01/14/2013 11:56 AM, Stefano Lattarini wrote: > 1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc' > or 'clang') supports "-c -o" together. Why? If the user has a > broken base vendor compiler, but has installed a better one (say > GCC), why should he still b

Re: AWK script has no effect when .in file has CRLF

As far as I know, all the autoconf tools are text based, so if your file has CRLF endings it should work. However, autoconf uses other commands (like sed) and they all need to be on the same page here. My guess (without really knowing) is that it's a bug in your 'sed' implementation, but I'm afra

Re: [PATCH] AC_SYS_LARGEFILE: define _DARWIN_USE_64_BIT_INODE conditionally

rt. I pushed the following, which should fix your problem. I'll follow up on bug-gnulib, as Gnulib has a similar issue. >From 57e2988c3ff664c57547c985c4d3e826fc98e208 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 16 Jan 2013 09:27:15 -0800 Subject: [PATCH] AC_SYS_LARGEFILE: por

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

On 01/16/13 04:46, Stefano Lattarini wrote: > Makes sense. Should I try to implement something along these lines (might > take a few days), or are you planning to do that yourself (in which case > I'll avoid the duplicated efforts)? I wasn't planning on doing that, so please go ahead.

Re: [GNU Autoconf 2.69] testsuite: 503 failed

Thanks for reporting that. I pushed the following change; does it fix the bug for you? >From d38c9d2c9c7f0a20308f0982a9f6b3836640942f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 29 Jan 2013 13:46:48 -0800 Subject: [PATCH] autoscan: port to perl 5.17 * bin/autoscan.in (scan_sh_f

Re: AC_FUNC_SETPGRP fails to work properly when cross-compiling

Thanks for the bug report. I installed the following somewhat-different patch. >From 73c32ee293da657d9f1e3754a017b1c2ba219e4c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 13 Feb 2013 23:28:21 -0800 Subject: [PATCH] AC_FUNC_SETPGRP: work even when cross-compiling * lib/autoc

Re: problem with MKDIR_P defined as relative path to install-sh

On 02/28/13 05:31, Peter Johansson wrote: > would it make sense to defined MKDIR_P with absolute path instead Yes, that sounds reasonable, if someone could prepare a patch along those lines.

[sr #108262] Correct quoting for a parameter in the documentation

Update of sr #108262 (project autoconf): Status:None => Done ___ Follow-up Comment #1: Thanks, I pushed the attached documentation patch to explain things better. (file #27578)

[sr #108262] Correct quoting for a parameter in the documentation

Update of sr #108262 (project autoconf): Open/Closed:Open => Closed ___ Reply to this item at: ___

[sr #108262] Correct quoting for a parameter in the documentation

Follow-up Comment #3, sr #108262 (project autoconf): Yes, that's right, 'make' doesn't care about shell quoting; it interpolates regardless of what the shell thinks the quotes are. ___ Reply to this item at:

Re: suggested rule for remaking config.h is wrong

Thanks, I pushed this: >From b0bc98f6a1a0bc6e92522d3c51284b89a446e083 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 23 Apr 2013 21:42:41 -0700 Subject: [PATCH] doc: add missing semicolons to make rules Problem reported by Peter Eisentraut in <http://lists.gnu.org/archive/ht

Re: [GNU Autoconf 2.69] testsuite: 264 271 286 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 failed

Sounds like you don't have a properly installed and/or configured C++ and Fortran compilers. If so, I wouldn't worry about it, as far as Autoconf goes.

Re: Cannot Build on CentOS 6.x or Amazon Linux

Ron Cemer wrote: > configure.ac:20: error: Autoconf version 2.65 or higher is required This is an error message from Thrift, not from Autoconf, so it's not something that the Autoconf folks can do anything about. For more information about this particular problem see: https://issues.apache.org/j

Re: AC_LINK_IFELSE unexpectedly fails on Ubuntu 12.04

This would appear to be a problem in OpenJDK's configure.ac file, not in Autoconf itself, no? So you should send a bug report to the OpenJDK folks.

Re: AC_LINK_IFELSE unexpectedly fails on Ubuntu 12.04

David Pointon wrote: > AFAICT, the problem stems from a generated shell function called > ac_fn_cxx_try_link Sure, but that function depends on the appropriate -L, -I, -l, etc. options being set appropriately for your system, and if those options are messed up than that function won't work. It a

Re: AC_SYS_LARGEFILE and old OSX framework

On 10/30/2013 05:38 AM, Yann Diorcet wrote: > This may cause segmentation fault on generated file (certainly linked to a > different struct stat) This suggests that (1) parts of your software package includes config.h, which defines _DARWIN_USE_64_BIT_INODE and gets one struct stat, (2) other part

Re: AC_SYS_LARGEFILE and old OSX framework

On 10/30/2013 12:46 PM, Diorcet Yann wrote: > Could be an explanation. but how do you explain the issue on that > https://gitorious.org/glib/android/source/003dbec6c84798cb5c6a8759258f2b7180e5fa10:glib/gkeyfile.c#L354-1871 > S_ISREG is done just after fstat ... and there is #include "config.h". I

Re: AC_SYS_LARGEFILE and old OSX framework

Diorcet Yann wrote: > I tried your idea ... same result. It sounds like it's not an Autoconf-related problem, then. But you'll have to debug it, I'm afraid. Possibly your program is trying to store an ino_t value into an int variable; that could explain the problem.

Re: as_echo/bs_echo still required?

Gary V. Vaughan wrote: it looks like doing so effectively deprecates Solaris 7 support That's fine. Sun (now Oracle) stopped supporting Solaris 7 in August 2008. Even Solaris 8 is fair game now; its end of support was March 2012. (Solaris 9's end of support will be in October of this year.)

Re: autoconf-2.69 not compatible with ppc64le architecture

On 01/12/2014 11:45 PM, Madhu Pavan wrote: > I found that "autoconf-2.69" would require a patch to either config.guess or > needs to pick up the latest automake (1.13.4 or above) version from upstream. It sounds like you have a fix, then: just upgrade to the latest automake. Or, if that's not po

On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

Following up to the grep snapshot announcement in: http://lists.gnu.org/archive/html/platform-testers/2014-05/msg0.html That snapshot failed to build the shell scripts egrep and fgrep properly on Solaris 10, because it set "SHELL = /bin/sh" in src/Makefile, which caused the makefile to put

Re: bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

way to say "I need a POSIX shell" or at least "I need a shell that does substrings", but that's merely a wishlist item. >From 0ca1f6d79514189ef8db6e931f285cbaec9789ec Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 12 May 2014 11:38:28 -0700 Subject: [PATCH] egrep,

Re: False negative for $cross_compiling when cross-compiling

Thanks, I installed that.

[sr #108405] False negative for $cross_compiling when cross-compiling on Linux for Windows.

Update of sr #108405 (project autoconf): Status:None => Done Open/Closed:Open => Closed ___ Reply to this item at:

Re: configure checking for csh hash hack

Goldberg, Jon (Jon) wrote: When used in the context of groff-1.22, the script does the following: if echo ./conftest.sh | (csh >/dev/null 2>&1) >/dev/null 2>&1; That's not from autoconf; it's something groff itself does, so please report the bug to bug-gr...@gnu.org instead.

Re: configure checking for csh hash hack

Michael wrote: i am looking at the same problem compiling groff and found his report to them, in their reply they directed him to come here I assume "their reply" means Werner Lemberg's message here: http://lists.gnu.org/archive/html/bug-groff/2014-10/msg8.html i'm not seeing a solutio

Re: bug#20733: coreutils build problem

Eric Blake wrote: Actually, POSIX_does_ allow for missing words between 'in' and the terminator (; or newline) before 'do' (whether by a word that expands to nothing, or by omission of words), requiring that the body of the for statement is skipped in that case: Ah, sorry, I was thinking of pr

Re: bug#20733: coreutils build problem

Michael Felt wrote: GEN src/coreutils.h /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected. make: 1254-004 The error code from the last command is 2. This looks like the coreutils patch wasn't properly propagated somehow. What's the output of 'make V=1'?

Re: bug#20733: coreutils build problem

Michael Felt wrote: root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1 rm -f src/coreutils.h for prog in ; do prog=`basenam Yes, it looks like something went wrong in your build process and you're using a Makefile.in generated from unpatched sources. I just n

Re: [GNU Autoconf 2.69] testsuite: 501 failed

Aharon Robbins wrote: Any idea how soon Autoconf 2.70 will be out? I don't know of any plans, no. I suppose a new version is due, but we need someone to volunteer to actually generate a release.

Re: Support Apple X11 at /opt/X11

Thanks for the suggestion, I installed the attached slightly-different patch. >From 70ce53307e1d9ef3354c73ef7b0969bbc7392f43 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 7 Aug 2015 18:09:17 -0700 Subject: [PATCH] Add /opt/X11/include to X search path * lib/autoconf/libs

Re: Location of "file" is hard coded

John Frankish wrote: the configure scripts produced by autoconf/automake assume "file" is located at /usr/bin/file and report it missing otherwise. Can you show us how to reproduce the bug, by supplying a configure.ac and a way to invoke autoconf and configure? I'm not seeing it in my configu

Re: Location of "file" is hard coded

John Frankish wrote: I see it in almost every package I compile, in this case I took the first one I found, NetworkManager-1.0.4, which gives: That use of /usr/bin/file comes from NetworkManager-1.0.4/m4/libtool.m4, which is not part of Autoconf or Automake per se. I suggest reporting the bu

Re: about the test 501 that fail...

it's more conservative to run libtoolize in the C locale, so that we don't have to worry about locale encoding when doing the test. So I installed the attached patch instead; please give it a try. >From ed9031df1361c484f292551481aebc724d1ed40c Mon Sep 17 00:00:00 2001 From: Paul Eg

Re: about the test 501 that fail...

Eric Blake wrote: even in the C locale, libtool has switched from `' to '' quoting, so a regex looking for ASCII backtick as the leading quote character fails to match the new diagnostics. That regex looks for [`'] so it should work with the new libtool behavior in the C locale. Putting cu

Re: about the test 501 that fail...

christian fafard wrote: I tried your patch but unfortunately it doesn't work. It looks like you tried to apply that patch to Autoconf 2.69. It won't do the job there. You can try doing some software archaeology to figure out why, but it may be simpler to run bleeding-edge Autoconf instead.

Re: Shellology: ksh93 from OpenIndiana ${1+"$@"}

On 12/10/2015 05:55 AM, Pavel Raiskup wrote: Is this issue worth documenting in Shellology section withing autoconf.info? This probably should be fixed somehow in libtool, but I'm not yet sure what is the proper way. It should be documented. I suggest changing Autoconf and Libtool to recommen

Re: CRLF vs. LF and config.status defines

Karl Berry wrote: I.e., autoconf is not supported on CRLF filesystems I'd say that's probably correct, yes. CRLF is a pain to port to.

Re: Bug with AC_C_RESTRICT on non-GNU-C compiler when using GLIBC

On 02/22/2016 01:46 PM, Dwight Guth wrote: Currently there is a problem with the way the AC_C_RESTRICT macro behaves if you are using GLIBC with a C99-compliant compiler that does not define the __GNUC__ macro, but does define __restrict. Which compiler is this, exactly? What does it define __r

Re: Bug with AC_C_RESTRICT on non-GNU-C compiler when using GLIBC

ectly explains the current behavior). Yes, that's a typo in that comment. It should say "supported only directly". Anyway, does the attached hacky patch fix the problem? >From cd6c575c532931d9e7339be9f0263ff66a2d7e17 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 22 Feb 201

Re: spelling errors

On 01/23/2017 12:18 PM, Alexei Podtelezhnikov wrote: > Please fix these errors in the output comments. Thanks, could you turn this into a patch, relative to the Autoconf source code? That would help us fix the errors.

Re: autoreconf uses aclocal even when not needed

On 03/22/2017 03:15 AM, Max Horn wrote: so I have this project where I use autoconf and libtool, but*not* automake. Turns out that autoreconf insists on using tools from automake anyway, namely by invoking "aclocal" which is part of automake. T It won't do that if you supply your own acloca

Re: Starting /bin/sh in output configure file

Mohammad Akhlaghi wrote: It would be great if this first line of the configure script would also check for `CONFIG_SHELL' Unfortunately this does not work, as the operating system handles the first line before the configure script starts.

Re: [bug-gawk] mktime(3) not detected on FreeBSD with -static

Is there an additional flag I should pass to the configure script to make static linking work without modifying the configuration header? Yes, 'ac_cv_func_working_mktime=yes'. This will cause Gawk to use the FreeBSD mktime even though it is buggy. Quite possibly you won't notice the bugs.

Re: [bug-gawk] mktime(3) not detected on FreeBSD with -static

Václav Haisman wrote: How buggy is FreeBSD's `mktime()`? Links, bugs? See the mktime test program in gawk's 'configure' script. It probably comes from: http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/mktime.m4 Some mktime implementations are quite bad: they can go into infinite or seemi

[sr #109406] autoheader creates config.h.in file with wrong timestamp

Update of sr #109406 (project autoconf): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks for reporti

Re: autoreconf can leave config.h.in older than aclocal.m4

I recently installed a patch for that bug, here: https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=e5f5e535adec83b146bfc921d9005ecf6a846464

Re: AC_CHECK_HEADERS from git doesn't add newlines

Isn't this a bug in th3e nasm configury? There should be a newline in the SEP argument of m4_map_args_w.

Re: Please drop autoconf-2.13-compatible cross-compile detection

On 04/20/2018 02:08 PM, Niels Möller wrote: Can we please delete the fragile transitioning rules now? I'd favor that, too. Does anybody have time to write a good patch for this? Most of the work would be updating the documentation and test cases, I expect.

Re: copyright problem with install-sh, request for clean-room rewrite

Mathieu Lirzin wrote: According to ‘git blame’ I appear to not have touch this file, so if you think that I am eligible, I am volunteering on this rewriting task. Thanks for volunteering. Eric, do you think it would save time overall if you sent him the part of install-sh that you are sure is

Re: Building autoconf

mhkelley2...@gmail.com wrote: Is anyone here? I am trying to build a package (xlsxio) that requires autoconf, but I have not been able to get autoconf to work at all. Yes we're here, but MS-Windows is not our platform of choice and questions involving it are lower priority. You might try us

Re: autoconf: ./configure fails on cygwin for crosstool-ng-1.24.0

On 5/6/19 1:08 PM, Philipp wrote: > > Is there anything I can do to solve the problem? > If I have to provide more information I'll gladly do. It should work with your Bash. The fact that it fails with both your Bash, and with recent zsh, suggest a configuration problem of some sort (not a proble

Re: AC_C_BIGENDIAN narrowing short

Thanks, I installed that.

Re: "thread-safe" mkdir -p

Thanks for mentioning that; I installed the attached to fix it. >From 5a72a803bc4bc23f6a64dd8eed95535b1a3a144d Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 6 Oct 2019 01:37:56 -0700 Subject: [PATCH] Fix terminology typo in mkdir -p check MIME-Version: 1.0 Content-Type: text/pl

Re: remove _DARWIN_USE_64_BIT_INODE

Thanks, I installed the attached and have merged the first patch into Gnulib; the second patch merges the code with Gnulib. >From 8f582a83efca19d3bd4ae30197a4c3aa155ce84c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 21 Feb 2020 17:17:45 -0800 Subject: [PATCH 1/2] Remove definition

Re: Time for a release?

On 4/2/20 4:14 PM, Reuben Thomas via Bug reports for autoconf wrote: is there some reason why there can't be an interim release? We're working on it. I say "we" but it's mostly Zack.

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

On 4/11/20 12:28 PM, Harald van Dijk wrote: The up_to_date_p function uses mtime, which returns timestamps with second precision. Even if it were capable of returning higher precision timestamps, the file system might not support it. These days file systems typically do support it, so can't we

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

On 4/13/20 4:21 PM, Harald van Dijk wrote: For better or worse, FAT is the most universally accepted file system, and for that reason it is widely used. It does not even support second precision timestamps. Let's not worry much about that. In practice, little development of Automake-using sof

Re: AC_CHECK_FUNCS and -Werror

On 6/17/20 1:00 PM, Peter Häring wrote: > But if you have as CFLAG -Werror, for example if you use start the > configure process with > CFLAGS+=-Werror ./configure > then warning abuot the different types will cause the test to fail > despite the function is available. > > Possible solutions

Re: Cache variable name for AC_CHECK_LIBS

t;From c998ae7ca5f59780f8029abdd6bf40c6581c7e49 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 2 Jul 2020 22:23:59 -0700 Subject: [PATCH] Fix AC_CHECK_LIB quoting bug Problem reported by Bert Wesarg in: https://lists.gnu.org/archive/html/autoconf/2016-04/msg00020.html * lib/autoconf/libs.m4 (AC_CHECK_LIB): Fix q

[sr #110268] AC_RUN_IFELSE does not execute the test program although it could

Update of sr #110268 (project autoconf): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks for the bug

[sr #110266] Revert regression in Yacc support, and add Bison support

Update of sr #110266 (project autoconf): Status:None => In Progress ___ Follow-up Comment #1: Thanks for reporting this. I started the ball rolling on it by reverting the mistaken patch in

Re: [sr #110268] AC_RUN_IFELSE does not execute the test program although it could

On 7/15/20 1:39 PM, Bruno Haible wrote: Here's a proposed doc patch. Thanks, I installed that.

[sr #110265] document a problem with AC_EGREP_CPP and AC_EGREP_HEADER

Update of sr #110265 (project autoconf): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks, I installe

[sr #110269] AC_PROG_LEX failing

Update of sr #110269 (project autoconf): Status:None => Done ___ Follow-up Comment #6: Thanks for the bug report and detailed analysis. I looked into the commit that you mentioned, a

[sr #110269] AC_PROG_LEX failing

Update of sr #110269 (project autoconf): Open/Closed:Open => Closed ___ Reply to this item at: ___

[sr #109320] _AC_PROG_LEX_YYTEXT_DECL fails to compute LEXLIB correctly using the original AT&T lex if Xcode's flex is installed

Follow-up Comment #3, sr #109320 (project autoconf): The patch as installed has problems, due to its AC_MSG_ERROR failing out of 'configure'. Please see sr#110269 which discusses the problems and a further fix that I installed. ___ Reply to

[sr #110271] libSDL2 fails with autoconf 2.70

Update of sr #110271 (project autoconf): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks for followi

[sr #110267] Testsuite regressions from 2.69 on Solaris 10 (SPARC)

Update of sr #110267 (project autoconf): Status:None => Works For Me ___ Follow-up Comment #2: > neither /opt/SUNWspro/bin/cc nor any command named `make` is installed. 'make' is in /usr/ccs

<    1   2   3   4   5   6   >