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

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

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 egg...@cs.ucla.edu Date: Mon, 12 May 2014 11:38:28 -0700 Subject: [PATCH] egrep, fgrep: port to Solaris 10 /bin

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 21) /dev/null 21; 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 solution

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

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

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 egg...@cs.ucla.edu Date: Fri, 7 Aug 2015 18:09:17 -0700 Subject: [PATCH] Add /opt/X11/include to X search path * lib/autoconf

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: about the test 501 that fail...

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 Eggert &

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

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: 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

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

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

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

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

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

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

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: 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: 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: 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

Re: AC_C_BIGENDIAN narrowing short

Thanks, I installed that.

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

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 definit

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

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: 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: AC_DIAGNOSE not obsolete, please

On 10/6/20 10:31 AM, Zack Weinberg wrote: Seems reasonable. What do you think of the patches below? Those Autoconf patches look good to me, thanks.

[sr #110298] "Substitute and define special characters" test fails on NetBSD

Follow-up Comment #2, sr #110298 (project autoconf): POSIX suggests that the test relies on unspecified (undefined?) behavior if the output of the printf shell command is not properly encoded for the current locale. Have you tried running the test with LC_ALL="C" in the environment? If that

[sr #110296] AC_TYPE_PID_T defines pid_t incorrectly on 64-bit MSVC

Follow-up Comment #3, sr #110296 (project autoconf): > maybe an entry in the NEWS file is appropriate? I didn't think the patch important enough to mention in NEWS. No big deal either way. ___ Reply to this item at:

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

On 10/21/20 6:15 AM, Zack Weinberg wrote: We*could* add a special case in AC_INIT where, if any of the third, fourth, or fifth arguments contain the literal strings `AC_PACKAGE_NAME` or `AC_PACKAGE_VERSION`, those are replaced with the values of the first and second argument, respectively.

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 #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

[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

[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

[sr #110273] New test suite failures of 2.69b on OpenBSD 6.5

Follow-up Comment #5, sr #110273 (project autoconf): There's no 'gmake' on my OpenBSD 6.7 platform, so I assume you built and installed your own copy of GNU Make. One possibility is that you need to be consistent about which 'make' you're using, e.g., './configure MAKE=gmake'. Or you might try

[sr #108092] AC_PROG_GREP can select /usr/xpg4/bin/grep under Solaris 9 but it doesn't support long lines

Follow-up Comment #2, sr #108092 (project autoconf): The problem occurs on Solaris 9 but not Solaris 10. Since Oracle dropped support for Solaris 9 in 2014, the scenario of the original bug report is no longer worth worrying about. However, if 'configure' is picking the wrong 'grep' that is a bug

[sr #110287] Two new test failures in automake-1.16.2 with autoconf-2.67b

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

[sr #110283] 2.69b on OpenIndiana: many testsuite failures without GNU utilities in $PATH

Follow-up Comment #2, sr #110283 (project autoconf): The ksh93 'rm -f' problem comes from this code introduced in Automake 1.14 (2013): https://git.savannah.gnu.org/cgit/automake.git/commit/?id=f78b0f0b2741fcdd4e21151758a8a75ddaa8aa17 This causes AM_INIT_AUTOMAKE to error-out immediately if 'rm

[sr #110284] 2.69b on OpenIndiana: one testsuite failure with GNU utilities in $PATH

Update of sr #110284 (project autoconf): Status: Need Info => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: I cannot

[sr #110283] 2.69b on OpenIndiana: many testsuite failures without GNU utilities in $PATH

Follow-up Comment #3, sr #110283 (project autoconf): I did not observe the _AST_FEATURES problem in any of my builds on OpenIndiana. However, Zack's patch looks good to fix those problems, whatever happens to cause them. ___ Reply to this

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

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

Re: [GNU Autoconf 2.69] testsuite: 203 264 271 286 311 312 313 314 315 316 323 328 339 503 failed

A quick look at the first couple of failures indicates that they were fixed by patches to Autoconf that were installed after 2.69b came out, in particular: https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=7c08375081545e1eaf96461319ffec0a02e9f959

[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

[sr #110272] New test suite failure of 2.69b on Solaris 11 OpenIndiana

Update of sr #110272 (project autoconf): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: I think Zack

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

e attached patch to fix this test glitch. The basic idea is to test 250 columns not 253, and to document the limit as 250 not 254. >From 79e8cc6a259d9af185356a9e56be6989f6185c64 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 17 Jul 2020 15:06:49 -0700 Subject: [PATCH] Test AC_FC_LINE_LENGT

Re: [GNU Autoconf 2.69] testsuite: 203 264 271 286 311 312 313 314 315 316 323 328 339 503 failed

On 7/14/20 9:22 AM, Dennis Clarke wrote: I was surprised to see many failures : I suggest trying Autoconf 2.69b (which happened to be announced about the same time you sent your bug report). See: https://lists.gnu.org/r/autoconf/2020-07/msg6.html Better yet, try 2.69b with the

[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,

[sr #109320] _AC_PROG_LEX_YYTEXT_DECL fails to compute LEXLIB correctly using the original AT 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

[sr #110269] AC_PROG_LEX failing

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

[sr #110273] New test suite failures of 2.69b on OpenBSD 6.5

Follow-up Comment #7, sr #110273 (project autoconf): > How about writing ${MAKE-make} instead? Thanks, that makes sense. I looked for other examples of the problem and installed patches to fix them: Prefer ‘$(MAKE)’ to ‘make’ in Makefiles

[sr #110273] New test suite failures of 2.69b on OpenBSD 6.5

Update of sr #110273 (project autoconf): Status:Works For Me => Done Open/Closed:Open => Closed ___ Reply to this item at:

Re: AC_F77_LIBRARY_LDFLAGS adds LLVM compiler flags to FLIBS

the attached, which I hope works around your particular problem. Please give it a try. >From ae26b9b44c183c41b84fc36ff70082713295d621 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 22 Jul 2020 12:56:19 -0700 Subject: [PATCH] Port AC_F77_LIBRARY_LDFLAGS to oneAPI HPC Toolkit MIME-Version:

Re: [GNU Autoconf 2.69] testsuite: 203 264 271 286 311 312 313 314 315 316 323 328 339 503 failed

On 7/22/20 1:42 PM, Dennis Clarke wrote: I attached a tarball that has everything about the procedure and the results. I have yet to go digging in there but figured I would post this first and then climb down into the test results and look around. Nothing was attached to your email,

[sr #110273] New test suite failures of 2.69b on OpenBSD 6.5

Update of sr #110273 (project autoconf): Status:None => Works For Me ___ Follow-up Comment #3: Odd, I just now tried a fresh OpenBSD 6.5 installation (amd64 guest on Ubuntu 18.04.3 host via

[sr #110387] Document better where to put -m32 or -m64 compiler options

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

[sr #110399] turning off preference for newest supported C?

Follow-up Comment #2, sr #110399 (project autoconf): Although this is a feature request, isn't there a bug report buried in it too? Karl reports: ./c-auto.h:164:22: error: two or more data types in declaration specifiers #define int64_t long int and ascribes this to 'gcc -std=gnu11'. However,

Re: Side effect ? autogen can not be built with autoconf-2.69d on Solaris 11.3 x86/x64.

On 11/28/20 11:39 PM, kabu_ha_genbu...@yahoo.co.jp wrote: Hello, Autogen-5.18.16 can not be built with autoconf-2.69d. I don't observe this problem when building autogen 5.18.16. It doesn't even run 'autoconf' when configuring (which is as things should be). Have you changed the autogen

Re: Side effect ? autogen can not be built with autoconf-2.69d on Solaris 11.3 x86/x64.

On 11/30/20 12:53 PM, Zack Weinberg wrote: We could expand the "for compatibility's sake" to set the cache variables ac_cv_header_{stdlib,string}_h (without actually bothering to check) but I'm not sure that's a good idea -- that would prevent people with a genuine need to maintain compatibility

[sr #110399] turning off preference for newest supported C?

Follow-up Comment #4, sr #110399 (project autoconf): For what it's worth, I ran into a similar problem on Fedora 33 with Gnulib, and found that it occurred because the Gnulib stdint module assumed that AC_INCLUDES_DEFAULT was being called and that it set ac_cv_header_inttypes_h and

[sr #110398] autoconf 2.70 breaks coreutils-8.32

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

[sr #110400] autoconf 2.70 no longer supports clang with -Wextra-semi-stmt warning enabled

Follow-up Comment #5, sr #110400 (project autoconf): > I'm not all that familiar with clang. Does anyone have a better idea for how to handle this quirk it has? Commit 82ef7805faffa151e724aa76c245ec590d174580

[sr #110375] AC_LANG_SAVE and AC_LANG_RESTORE should not be marked obsolete

Follow-up Comment #1, sr #110375 (project autoconf): [comment #0 original submission:] > I think AC_LANG_SAVE and AC_LANG_RESTORE should not be marked obsolete, until a libtool.m4 release exists that does not use them any more. It does sound reasonable to not warn about them for now, even if we

[sr #110353] AC_OPENMP leaves a file named "penmp" in the srcdir with Sun C 5.9

Follow-up Comment #1, sr #110353 (project autoconf): "have AC_OPENMP check before its main loop that no files named 'penmp' or 'mp' exist. If they do, it aborts, because the problem compiler invocations would clobber those files. If they don't, though, then it can safely delete them afterward."

[sr #110364] obsolete agony

Follow-up Comment #2, sr #110364 (project autoconf): I lean towards agreeing with Zack, in that the warnings are typically more helpful than harmful and should be on by default. If it helps, I can volunteer to patch texlive to pacify the new Autoconf. The patches should all be simple.

Re: bad file descriptor / bad substitution

On 1/1/21 3:56 PM, Thien-Thi Nguyen wrote: Is this a simple case of user error (‘AC_CHECK_DECLS’ should be m4-quoted) Yes. That AC_CHECK_DECLS expands into a string that contains this line: # freestanding implementations, so test against a dummy and the comma is treated as an argument

[sr #110480] Generated configure script has errors

Follow-up Comment #1, sr #110480 (project autoconf): The bug report doesn't contain enough info to reproduce the problem. That being said, most likely the problem is that the SANE project's configure.ac (or some .m4) file is underquoting. If so, it's not an Autoconf bug. See:

Re: autoconf-2.71 regression with intltool IT_PROG_INTLTOOL/AC_PROG_INTLTOOL macro

On 3/31/21 11:22 PM, Ondrej Dubaj wrote: libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am. ERROR: 'IT_PROG_INTLTOOL' must appear in configure.ac for intltool to work. autoreconf: error: intltoolize failed with exit status: 1 This appears to be a portability bug in

[sr #110451] autoconf 2.71 generated configure file does not enable C compiler flag for C99 on Solaris 10

Follow-up Comment #3, sr #110451 (project autoconf): Although Autoconf used -D_STDC_C99 for good reason, portable software nowadays expects C99 rather than C89 behavior, so I'd favor switching to -xc99 despite its global implications (what _was_ Sun thinking?). I suppose I count as an "active

[sr #110530] Missing #include in AC_FUNC_MEMCMP

Follow-up Comment #6, sr #110530 (project autoconf): [comment #5 comment #5:] > I don't know whether there was an alternative that Apple did not pursue in which implicit function declarations could have been allowed. Sure there was an alternative. They could have made

[sr #110530] Missing #include in AC_FUNC_MEMCMP

Follow-up Comment #9, sr #110530 (project autoconf): [comment #7 comment #7:] > Your getdtablesize example is inapplicable since a prototype is provided Oh, good point. As Zack mentioned, the -Wno-error=implicit-function-declaration issue is therefore irrelevant to the current bug report. At

[sr #110530] Missing #include in AC_FUNC_MEMCMP

Update of sr #110530 (project autoconf): Status:None => Invalid Open/Closed:Open => Closed Operating System: Mac OS => None

[sr #110521] autom4te does not always update cache, breaks if change happens within 1 second

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

[sr #110532] AC_CHECK_LIB no longer works with a C++ compiler

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

[sr #110503] Autoconf 2.70 problem: gkt-doc/gtkdocize is now unconditionally required

Update of sr #110503 (project autoconf): Status:None => Need Info Summary: Autoconf 2.70 regression: gkt-doc/gtkdocize is now unconditionally required => Autoconf 2.70 problem: gkt-doc/gtkdocize is now unconditionally required

[sr #110503] Autoconf 2.70 problem: gkt-doc/gtkdocize is now unconditionally required

Follow-up Comment #4, sr #110503 (project autoconf): [comment #3 comment #3:] > Can you clarify what you mean by self-contained example? All it takes is to create a configure.ac with the snippet I quoted in the previous comment and run > autoreconf -fiv. I mean a standalone shell script that

[sr #110530] Missing #include in AC_FUNC_MEMCMP

Follow-up Comment #4, sr #110530 (project autoconf): > Apple had to make this change in order to support Apple Silicon processors No it didn't. At best, Apple just doesn't care much about compatibility with GNU tools. A simple workaround would be for 'configure' to automatically add

[sr #110571] Autoconf-2.71 misconverts new-line escapes in AC_CHECK_FUNCS() argument

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

[sr #110518] Document that code snippets undergo shell variable expansion

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

Re: [1003.1(2016/18)/Issue7+TC2 0001558]: require [^...] in addition to [!...] for bracket expression negation

3 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 18 Feb 2022 15:03:00 -0800 Subject: [PATCH] Fix unwanted globbing of sed script Problem reported by mirabilos via Eric Blake in: https://www.austingroupbugs.net/view.php?id=1558 https://lists.gnu.org/r/bug-autoconf/2022-02/msg3.html * lib/m4

Re: set -e causes AS_IF to exit in else clause

Thanks for reporting that regression. I installed the attached patch.From 1684650184aea9ed51ded79680bb1b4fcb098f26 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 31 Mar 2022 22:29:05 -0700 Subject: [PATCH] =?UTF-8?q?Fix=20bug=20with=20AS=5FIF=20and=20=E2=80=98set?= =?UTF-8?q?=20-e=E2=80

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

Update of sr #110657 (project autoconf): Priority: 5 - Normal => 3 - Low Status:None => Need Info ___ Follow-up Comment #1: > For example,

[sr #110656] On AT UnixPC (3b1), parameter $3 gets overwritten (cleared) by call to subfunction.

Update of sr #110656 (project autoconf): Status:None => Wont Do Open/Closed:Open => Closed ___ Follow-up Comment #2: For this one I

[sr #110655] AT UnixPC (3b1) shell thrown off by #( after case.

Update of sr #110655 (project autoconf): Status:None => Wont Do Open/Closed:Open => Closed ___ Follow-up Comment #1: The #( is not

[sr #110653] configure fails on AT UnixPC (3b1) due to faulty LINENO substitution

Update of sr #110653 (project autoconf): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: Closing this as a

[sr #110654] On AT UnixPC (3b1) autoconf script fails to properly replace $LINENO variable with line number

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

[sr #110660] AC_LANG_INT_SAVE (used by AC_CHECK_SIZEOF) includes stdlib.h without checking whether it actually exists

Update of sr #110660 (project autoconf): Priority: 5 - Normal => 3 - Low Severity: 3 - Normal => 1 - Wish ___ Follow-up Comment #3: > This fails if

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

Update of sr #110657 (project autoconf): Status: Need Info => Wont Do ___ Follow-up Comment #3: OK, I think I see what's happening now; you have an egrep that's good enough, but you also

[sr #110657] Autoconf configure script considers absence of usable grep a fatal error, although it only uses egrep thereafter

Update of sr #110657 (project autoconf): Priority: 3 - Low => 1 - Later ___ Reply to this item at:

<    1   2   3   4   >