[sr #111272] autoreconf -i should invoke autopoint when configure.ac invokes AM_ICONV or AC_LIB_LINKFLAGS

Follow-up Comment #3, sr #111272 (group autoconf): Similarly, 'autopoint' needs to be invoked when the configure.ac contains an invocation of AM_PO_SUBDIRS or AC_LIB_LINKFLAGS_FROM_LIBS. How to reproduce regarding AM_PO_SUBDIRS: Download the chemical-mime-data_0.1.94.orig.tar.gz tarball from http

[sr #111272] autoreconf -i should invoke autopoint when configure.ac invokes AM_ICONV or AC_LIB_LINKFLAGS

Follow-up Comment #2, sr #111272 (group autoconf): Similarly, 'autopoint' needs to be invoked when the configure.ac contains an invocation of AM_GNU_GETTEXT without an invocation of AM_GNU_GETTEXT_VERSION or AM_GNU_GETTEXT_REQUIRE_VERSION. How to reproduce: Download the gnujump_1.0.8.orig.tar.gz

[sr #111273] autoreconf -i should use option "-I m4" after running autopoint

Follow-up Comment #1, sr #111273 (group autoconf): Find attached a proposed fix, assuming the fix of sr#111272 as prerequisite. Tested on the mozo, grcompiler, and libmatheval tarballs. (file #57364) ___ Additional Item Attachment: File n

[sr #111273] autoreconf -i should use option "-I m4" after running autopoint

ing System: None ___ Follow-up Comments: --- Date: Mi 02 Jul 2025 02:55:14 CEST By: Bruno Haible A list of 'autoreconf' failures, reported by Debian, was analyzed in https://lists.gnu.org/archive/html/bug-gettext

[sr #111272] autoreconf -i should invoke autopoint when configure.ac invokes AM_ICONV or AC_LIB_LINKFLAGS

Follow-up Comment #1, sr #111272 (group autoconf): Find attached a proposed fix. Tested on the grcompiler and libmatheval tarballs mentioned above. (file #57356) ___ Additional Item Attachment: File name: 0001-autoreconf-Invoke-autopoint-

[sr #111272] autoreconf -i should invoke autopoint when configure.ac invokes AM_ICONV or AC_LIB_LINKFLAGS

: None ___ Follow-up Comments: --- Date: Mi 02 Jul 2025 02:47:24 CEST By: Bruno Haible A list of 'autoreconf' failures, reported by Debian, was analyzed in https://lists.gnu.org/archive/

[sr #111271] autoreconf should ignore spaces before AM_GNU_GETTEXT invocation

: None ___ Follow-up Comments: --- Date: Mi 02 Jul 2025 01:32:54 CEST By: Bruno Haible Forwarded from https://savannah.gnu.org/bugs/?52424 : Kip writes: The following is consumed just fine by autoreconf. ... AM_GNU_G

[sr #111256] provide AC_CHECK_TOOL* variants that support a custom test

: None ___ Follow-up Comments: --- Date: Do 12 Jun 2025 18:54:49 CEST By: Bruno Haible The macros AC_CHECK_PROGS, AC_CHECK_TOOL, AC_CHECK_TOOLS, AC_PATH_PROG, AC_PATH_PROGS, documented in https://www.gnu.org/savannah-checkou

[sr #111238] downstream package build failure with autoreconf+gettext-0.24.1

Follow-up Comment #7, sr #111238 (group autoconf): Re comment #6: >> 1) ... But then the distros say "we don't trust upstream tarballs any more, >> because of the xz backdoor drama", and regenerate everything with their own >> versions of autoconf, automake, ... > > Please do not tar and feather

[sr #111238] downstream package build failure with autoreconf+gettext-0.24.1

Follow-up Comment #5, sr #111238 (group autoconf): Zack: > the intended purpose of autoreconf is to be a complete substitute for > project-specific autogen.sh scripts. The documentation https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/autoreconf-Invocation.html

Re: AC_CHECK_DECL has wrong results on macOS

onnull __l) __INTRODUCED_IN(26); wctrans_t _Nonnull wctrans_l(const char* _Nonnull __name, locale_t _Nonnull __l) __INTRODUCED_IN(26); #endif /* __ANDROID_API__ >= 26 */ 2025-05-31 Bruno Haible Make gl_CHECK_FUNCS_MACOS work with current unreleased Autoconf. Reported by Paul Egg

fix quoting in trap command

E=\"foo\" -DPACKAGE_TARNAME=\"foo\" -DPACKAGE_VERSION=\"0\" -DPACKAGE_STRING=\"foo\ 0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"foo\" -DVERSION=\"0\" -DHAVE_STDIO_H=1 ... So, obviously, there is a quo

Re: AC_CHECK_DECL has wrong results on macOS

Hi Paul, > > Here's a proposed fix for the issue along these lines. > > Thanks. It'd be nicer if AC_CHECK_DECL didn't require AC_CANONICAL_HOST. > We can do that by checking inside the C program rather than using > AC_CANONICAL_HOST. This comes with the cost of an extra compiler invocation on

Re: AC_CHECK_DECL has wrong results on macOS

ns from future Darwin versions... -Werror=unguarded-availability-new ... checking whether mkfifoat is declared... no ... $ make $ ./foo $ echo $? 0 >From 4d54a043a646471c18ec2ebdd7d5f6f446187982 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sat, 24 May 2025 12:22:28 +0200 Subject: [PATCH] Fix AC_CH

AC_CHECK_DECL has wrong results on macOS

Hi, In Autoconf 2.70 the following bug was fixed: "AC_CHECK_DECL and AC_CHECK_DECLS will now detect missing declarations for library functions that are also Clang compiler builtins." For example, the AC_CHECK_DECLS([strndup]) invocation, on a glibc system, with CC="clang -D_POSIX_C_SOURCE=200

[sr #111238] downstream package build failure with autoreconf+gettext-0.24.1

Follow-up Comment #3, sr #111238 (group autoconf): Funda Wang, I gave an answer to your question in https://savannah.gnu.org/bugs/?67090 on May 7, 2025. The next day, you come here to the Autoconf tracker and suggest to the Autoconf people to make a change that makes my bug fix in GNU gettext ine

[sr #111238] downstream package build failure with autoreconf+gettext-0.24.1

Follow-up Comment #2, sr #111238 (group autoconf): This issue has been discussed in https://savannah.gnu.org/bugs/?67090 and closed. The resolution was: *The problem is the use of autoreconf.* > May autoreconf script be tweaked, so that "-I/usr/share/gettext/m4/" be used > when involking autocon

Re: fedora 42 doesn't have awk: how to deal with autoconf subst?

Simon Josefsson wrote: > I'm concerned about rewriting efforts, they tend to never get finished. Right. And the target of the rewrite should be something that is not changing rapidly. Because users in the year 2040 should be able to take a tarball packaged in 2030 and configure and build it. This

Re: fedora 42 doesn't have awk: how to deal with autoconf subst?

Simon Josefsson wrote: > It seems awk is going away as a standard tool, and it is possible to > either fight that or just accept it. I don't think that the set of "standard tools" is shrinking. Rather, it's expanding. On OpenBSD for example, perl is installed by default. Similarly, Python is consi

Re: fedora 42 doesn't have awk: how to deal with autoconf subst?

Simon Josefsson wrote: > the docker container images (which are typically > used for CI) or the cloud images (which are typically used in Kubernetes > environments). I'm not sure there is a trend that container images for > OS's are growing, I think most distributions are actively trying to make >

Re: fedora 42 doesn't have awk: how to deal with autoconf subst?

Jeffrey Walton wrote: > Awk is a standard Posix utility: > . The newest POSIX is POSIX:2024. Update your URLs: . Bruno

Re: fedora 42 doesn't have awk: how to deal with autoconf subst?

Simon Josefsson wrote: > 0) Modify autoconf to continue to work in this situation without awk, > replacing it with more POSIX shell or something else? Many years ago, Autoconf produced configure scripts that used 'sed' for the job of replacing the various @FOO@ occurrences in *.in files. When

Re: warning "seems to ignore the --datarootdir setting"

Nick Bowler wrote: > Substituting > directory variables at configure time is basically impossible to do in a > manner that is compliant with the GNU coding standards, because the > standards say that the user can specify prefix on the make command line > instead of (or in addition to) the configure

warning "seems to ignore the --datarootdir setting"

Hi, In the attached tarball, autoconf 2.72 emits a warning at configure-time because one of the files substitutes a value for @localedir@. How to reproduce: $ tar xfz hello-rust-0.tar.gz $ cd hello-rust-0 $ ./configure --prefix=/tmp/inst --datarootdir=/tmp/dataroot ... configure: creating ./conf

[sr #111055] AC_OPENMP fails with Apple Clang

Follow-up Comment #2, sr #111055 (group autoconf): Oh, and I disagree with the "Severity: Important". A user who wants to use these command-line option can already do so via CC="clang -Wp,-fopenmp" CXX="clang++ -Wp,-fopenmp". No functionality is lost by the current state of AC_OPENMP. __

[sr #111055] AC_OPENMP fails with Apple Clang

Follow-up Comment #1, sr #111055 (group autoconf): > Apple Clang requires passing "-Xpreprocessor -fopenmp" rather than just -fopenmp. Actually, either "-Xpreprocessor -fopenmp" or "-Wp,-fopenmp". However, libtool (version 2.5.3) supports only "-Wp,-fopenmp". If you try compiling a library with

make AC_PROG_OBJC work out-of-the-box on RHEL 9 and compatible systems

Find attached a proposed patch that makes this work out-of-the-box. Bruno [1] https://bugzilla.redhat.com/show_bug.cgi?id=1826731 [2] https://packages.fedoraproject.org/pkgs/gcc-epel/gcc-objc/ [3] https://fedoraproject.org/wiki/User:Robert >From e19f43b9bdefd8547d9056ae99de3e20e311e1e4 Mon

Re: ac_cv_sys_largefile_opts undocumented?

dmitrii.pasechnik wrote: > By the way, ac_cv_sys_largefile_opts isn't fun to use - as sometimes > it's a plain text, and sometimes flags which should be added to CFLAGS. > So one has to write things like > > AS_CASE([$ac_cv_sys_largefile_opts], > ["none needed"], [], > ["support not detected"]

Re: autoreconf --force seemingly does not forcibly update everything

Nick Bowler wrote: > Not including the scripts used to build configure in a source tarball > is a mistake, particularly for a GPL-licensed package. The configure > script itself is clearly object code, and the GPL defines corresponding > source to include any "scripts to control [its generation]".

Re: autoreconf --force seemingly does not forcibly update everything

Bernhard Voelker wrote: > > Last month, I spent 2 days on prerelease testing of coreutils. If, after > > downloading the carefully prepared tarball from ftp.gnu.org, the first > > thing a distro does is to throw away the *.m4 files and regenerate the > > configure script with their own one, >

Re: autoreconf --force seemingly does not forcibly update everything

Sam James replied to Bruno Haible who cited Nick Bowler: > >> If I distribute a release package, what I have tested is exactly what is > >> in that package. If you start replacing different versions of m4 macros, > >> or use some distribution-patched autoconf/a

Re: autoreconf --force seemingly does not forcibly update everything

Guillem Jover wrote: > > It may be unexpected to you, but it is very much intended. > > The only unexpected part (which I perhaps failed to convey) was that > it is being taken into account with --force. This is documented in https://www.gnu.org/software/automake/manual/html_node/Serials.html whe

Re: autoreconf --force seemingly does not forcibly update everything

Nick Bowler wrote: > If I distribute a release package, what I have tested is exactly what is > in that package. If you start replacing different versions of m4 macros, > or use some distribution-patched autoconf/automake/libtool or whatever, > then this you have invalidated any and all release te

Re: autoreconf --force seemingly does not forcibly update everything

Jeffrey Walton wrote: > Please forgive my ignorance... If you bump the authentic version of > the m4 file to version 31, will the issue mostly clear itself? If we bump gnulib's build-to-host.m4 to 'serial 31', this will override the one from xz-5.6.x in *some* situations. In other situations, it w

Re: autoreconf --force seemingly does not forcibly update everything

Thanks for the forward, Eric. Guillem Jover wrote in : > > Hi! > > > > While analyzing the recent xz backdoor hook into the build system [A], > > I noticed that one of the aspects why the hook worked was because it > > seems l

Re: Autoconf documentation link broken

Paul Eggert wrote: > Thanks, it should be working now. Yes, it works now. Thanks! Bruno

Autoconf documentation link broken

Hi, When visiting https://www.gnu.org/software/autoconf/manual/ the first hyperlink (_HTML (2220K bytes)_) works, but the second hyperlink (_HTML_) lands in a 404 error page. Bruno

[GNU Autoconf 2.72] testsuite: 19 failed

On OpenBSD 7.4 (ffs file system) and macOS 12.5 (apfs file system), "make check" fails. The failing test is: 19: tools.at:672 autoconf: timestamp changes Find attached the log files. ## - ## ## GNU Autoconf 2.72 test suite. ## ##

[GNU Autoconf 2.72] testsuite: 420 421 606 607 failed

On Debian GNU/Hurd from 2022, with CC="gcc-12" and CXX="g++-12", "make check" fails. The failing tests are: 420: semantics.at:908 AC_SYS_LARGEFILE 421: semantics.at:917 AC_SYS_YEAR2038 606: foreign.at:145 AX_PROG_CC_FOR_BUILD 607: foreign.at:179 AX_PROG_CXX_FOR_BUILD Find attache

[sr #110435] autoreconf: recognize when AM_ICONV is used without the rest of gettext

Follow-up Comment #8, sr#110435 (group autoconf): I think this bug should NOT be fixed. The reason is that ideally, there should be one and only one tool responsible for installing config.rpath in the developer's package when needed. It's already bad enough that three(!) tools do this: gettextize

Re: autoconf-2.72d on other platforms

It build fine, and "make check" passes, on: - Ubuntu 22.04 - CentOS 7 - Alpine Linux 3.18 - macOS 12.5 - FreeBSD 13.2 and 14.0 Bruno

Re: autoconf-2.72d on Cygwin

On Cygwin 2.9.0, with GNU make 4.2.1, a couple of tests hang: 221 (parallel test execution) 225 (parallel syntax error) 226 (parallel errexit) 227 (parallel autotest and signal handling) Other than that, no test failures.

Re: autoconf-2.72d on Solaris 11 OpenIndiana: testsuite: 260 445 446 510 failed

On Solaris OpenIndiana/x86_64, with - GNU m4 version 2022-12-24 - 'awk --version' => awk version Aug 27, 2018 - no bison, but yacc "make check" gives 4 test failures. Failed tests: GNU Autoconf 2.72d test suite test groups: NUM: FILE-NAME:LINE TEST-GROUP-NAME KEYWORDS 260: tort

Re: autoconf-2.72d on CentOS 8: testsuite: 11 failed

Zack Weinberg wrote: > Ugh, this is probably a cache timestamps issue. Ouch, another one? The first cache timestamp issue is supposed to be fixed. > Can you please post the output of > > find . -printf '%T+\t%P\n' | sort > s

autoconf-2.72d on CentOS 8: testsuite: 11 failed

On CentOS 8/x86_64, "make check" gives 1 test failure: test #11 fails. ## -- ## ## GNU Autoconf 2.72d test suite. ## ## -- ## testsuite: command line was: $ tests/testsuite -C tests MAKE=make ## -- ## ## ChangeLog. ## ## -

Re: two recent NEWS entries

Paul Eggert wrote: > Thanks for mentioning that. I installed the attached to try to clarify > things. Thanks! It's clear now. Bruno

two recent NEWS entries

Hi, I'm trying to understand the NEWS entries for Autoconf 2.72. 1) I don't understand this paragraph: *** New macros AC_SYS_LARGEFILE_REQUIRED and AC_SYS_YEAR2038_REQUIRED. These act like AC_SYS_LARGEFILE and AC_SYS_YEAR2038 respectively, except that they require large-file and year-2

[sr #110324] autoupdate does some nonsensical changes

Follow-up Comment #3, sr #110324 (project autoconf): Since autoupdate uses a "brittle" algorithm, as Zack wrote, I think what you report will be hard or impossible to reproduce if you don't attach the input file(s). ___ Reply to this item

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

Follow-up Comment #2, sr #110518 (project autoconf): Very nice! Thank you. (And I had not thought about the backquote character.) ___ Reply to this item at:

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

URL: Summary: Document that code snippets undergo shell variable expansion Project: Autoconf Submitted by: haible Submitted on: Sun 18 Jul 2021 10:51:05 AM CEST Category: None

[sr #110492] Some tests failed on Mac OS X Catalina, please see the logfile.

Follow-up Comment #1, sr #110492 (project autoconf): /usr/local/bin/m4 --version GNU M4 1.4.6 Copyright (C) 2006 Free Software Foundation, Inc. The README file says: "You should install GNU M4 (version 1.4.6 or later is required; 1.4.14 or later is recommended)" Please try with a more recent G

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

Follow-up Comment #12, sr #110403 (project autoconf): The bug exists also in the /bin/sh of Solaris OpenIndiana 20171031. The symptom is this failure during configure: configure: creating ./config.status config.status: creating Makefile gawk: ./conf0h1pqt/subs.awk:1691: cat >>"$ac_tmp/subs1.awk"

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

Follow-up Comment #4, sr #110451 (project autoconf): > AC_PROG_CC(_C99) intentionally doesn't use -xc99 with Sun's compilers. ... see the thread starting at: https://lists.gnu.org/archive/html/autoconf/2010-12/msg00059.html Indeed, this option, together with the per-program flags __xpg4 and __xpg

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

Follow-up Comment #1, sr #110451 (project autoconf): I'm attaching the config.cache and config.log files in each of the two tarballs. (file #50942) ___ Additional Item Attachment: File name: config-files.tar.gzSize:11 KB

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

URL: Summary: autoconf 2.71 generated configure file does not enable C compiler flag for C99 on Solaris 10 Project: Autoconf Submitted by: haible Submitted on: Sat 27 Feb 2021 09:05:03 PM CET

[sr #110435] autoreconf does not recognize AM_ICONV

Follow-up Comment #1, sr #110435 (project autoconf): > https://lists.gnu.org/archive/html/bug-gettext/2011-10/msg00012.html > When a project wants to only use AM_ICONV and none of the other gettext autoconf macros If your package only wants to use iconv() but no support for localized messages, it

[sr #110425] autoconf 2.70 generated configure file does not enable -std=gnu99 on Mac OS X 10.5

Follow-up Comment #3, sr #110425 (project autoconf): Thanks. I confirm that it is fixed in Autoconf 2.71. ___ Reply to this item at: ___ Message se

[sr #110425] autoconf 2.70 generated configure file does not enable -std=gnu99 on Mac OS X 10.5

Follow-up Comment #1, sr #110425 (project autoconf): With autoconf master as of 2021-01-15, the problem is fixed. I.e. the generated configure script now adds '-std=gnu99' to $CC again. ___ Reply to this item at:

[sr #110425] autoconf 2.70 generated configure file does not enable -std=gnu99 on Mac OS X 10.5

URL: Summary: autoconf 2.70 generated configure file does not enable -std=gnu99 on Mac OS X 10.5 Project: Autoconf Submitted by: haible Submitted on: Sat 16 Jan 2021 11:49:59 AM CET

Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

Bob Friesenhahn wrote: > > I would recommend to just document the problem and workaround in two places: > > 1) in the OmniOS community, > > 2) at https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration for > > GNU people. > > That seems reasonable. OK, what can I write in (2)? Are the

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

Follow-up Comment #8, sr #110403 (project autoconf): Given that * OmniOS has an active development [1], * The OpenSolaris community is approximately equally divided among OmniOS, SmartOS, and OpenIndiana [2], * You haven't found this bug in other Solaris derivatives, * The workaround is to set the

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

Follow-up Comment #2, sr #110400 (project autoconf): The workaround is to add option -Wno-extra-semi-stmt after the -Wall option, e.g. on Windows systems: CC="$HOME/compile clang-cl -Wall -Wno-extra-semi-stmt". ___ Reply to this item at:

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

Follow-up Comment #1, sr #110400 (project autoconf): The error happens in the expansion of the macro _AC_UNDECLARED_WARNING: # For AC_CHECK_DECL to react to warnings, the compiler must be silent on # valid AC_CHECK_DECL input. No library function is consistently available # on fre

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

URL: Summary: autoconf 2.70 no longer supports clang with -Wextra-semi-stmt warning enabled Project: Autoconf Submitted by: haible Submitted on: Sat 12 Dec 2020 02:58:29 AM CET Ca

[sr #110294] AC_LANG_PUSH/AC_LANG_POP malfunction inside AC_DEFUN

Follow-up Comment #5, sr #110294 (project autoconf): Your workaround works perfectly! I'm using it in gnulib now: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=a0654cff8f1cbb705fbcba80841c58747b993440 Many many thanks!! > After a bunch of head-scratching I have figured out what

[sr #110294] AC_LANG_PUSH/AC_LANG_POP malfunction inside AC_DEFUN

Follow-up Comment #3, sr #110294 (project autoconf): Comment #2 was truncated. It was meant to read: After a bunch of head-scratching I have figured out what's going on. This code AC_LANG_PUSH([C++]) AC_CACHE_CHECK([whether the C++ compiler has ], [gl_cv_cxxheader_cuchar], [

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

URL: Summary: Document better where to put -m32 or -m64 compiler options Project: Autoconf Submitted by: haible Submitted on: Tue 01 Dec 2020 11:00:50 PM CET Category: None

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

URL: Summary: AC_LANG_SAVE and AC_LANG_RESTORE should not be marked obsolete Project: Autoconf Submitted by: haible Submitted on: Fri 13 Nov 2020 11:57:37 PM CET Category: None

[sr #110347] Revise documentation of when configure enters cross-compilation mode.

Follow-up Comment #1, sr #110347 (project autoconf): This documentation was already improved through https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=fc1fe985411216165116520b444cdeaae237b6fb It now says "If the binaries produced by these tools can be executed by the build system

[sr #110305] Replace autom4te output file atomically

Follow-up Comment #1, sr #110305 (project autoconf): Gnulib has a module 'supersede', for atomically superseding an output file. But it's written in C, not Perl. So, probably, it's not useful here? ___ Reply to this item at:

[sr #110325] autoupdate introduces a second invocation of AC_OUTPUT

URL: Summary: autoupdate introduces a second invocation of AC_OUTPUT Project: Autoconf Submitted by: haible Submitted on: Mon 05 Oct 2020 12:57:35 AM CEST Category: None

[sr #110324] autoupdate does some nonsensical changes

URL: Summary: autoupdate does some nonsensical changes Project: Autoconf Submitted by: haible Submitted on: Mon 05 Oct 2020 12:34:05 AM CEST Category: None Priorit

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

Follow-up Comment #2, sr #110296 (project autoconf): Sure. I didn't pay attention to this terminology detail. Also, maybe an entry in the NEWS file is appropriate? ___ Reply to this item at: _

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

Additional Item Attachment, sr #110296 (project autoconf): File name: 0001-AC_TYPE_PID_T-Define-pid_t-correctly-on-64-bit-nativ.patch Size:1 KB

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

URL: Summary: AC_TYPE_PID_T defines pid_t incorrectly on 64-bit MSVC Project: Autoconf Submitted by: haible Submitted on: Mon 24 Aug 2020 01:36:11 AM CEST Category: None

[sr #110294] AC_LANG_PUSH/AC_LANG_POP malfunction inside AC_DEFUN

Follow-up Comment #1, sr #110294 (project autoconf): The comment at _AC_LANG_SET in lang.m4 says "... it can introduce differences between the sh-current language and the m4-current-language when m4_require is used." Maybe there are other situations where the sh-current language and the m4-curren

[sr #110294] AC_LANG_PUSH/AC_LANG_POP malfunction inside AC_DEFUN

URL: Summary: AC_LANG_PUSH/AC_LANG_POP malfunction inside AC_DEFUN Project: Autoconf Submitted by: haible Submitted on: Tue 18 Aug 2020 06:38:28 PM CEST Category: None

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

Follow-up Comment #8, sr #110273 (project autoconf): Thanks. I confirm that with these patches, and when I set the environment variable MAKE=gmake, all tests pass. You can close this ticket. ___ Reply to this item at:

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

Follow-up Comment #6, sr #110273 (project autoconf): > There's no 'gmake' on my OpenBSD 6.7 platform It's part of the add-on packages. Here's my recipe to fetch it and a couple of other programs: # Install some packages. # List is at https://ftp.hostserver.de/pub/OpenBSD/6.7/packages/amd64/ # Se

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

Follow-up Comment #4, sr #110273 (project autoconf): > OpenBSD 6.5 is no longer supported I reproduce the problem with OpenBSD 6.7, both with an in-source build and a VPATH build. See the attached logs. > everything worked for me. I run ./configure && gmake && gmake check The error message i

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

Follow-up Comment #2, sr #110273 (project autoconf): Well, no, Zacks patch did not fix these. I've created a tarball from the newest git checkout, and ran it on OpenBSD 6.5. The tests 221 and 222 still fail. Logs are attached. (file #49504)

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

URL: Summary: New test suite failures of 2.69b on OpenBSD 6.5 Project: Autoconf Submitted by: haible Submitted on: Fri 17 Jul 2020 11:00:47 PM CEST Category: None

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

URL: Summary: New test suite failure of 2.69b on Solaris 11 OpenIndiana Project: Autoconf Submitted by: haible Submitted on: Fri 17 Jul 2020 10:53:04 PM CEST Category: None

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

ding packages with --host and without --build for 15+ years, and it works fine. - To care about the case of the buggy Wine emulator and how to avoid it, a sentence could be useful. Here's a proposed doc patch. >From 0f612d7ff8f3ac4ecbfe81b3935e46a779f40d6b Mon Sep 17 00:00:00 2

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

Follow-up Comment #1, sr #110268 (project autoconf): I believe that the cause is this commit: https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=fbec57294abd097fdc5894e0ec0d0133a0b5445b and that reverting it would fix the regression. The reasoning given in that commit was "modern

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

URL: Summary: AC_RUN_IFELSE does not execute the test program although it could Project: Autoconf Submitted by: haible Submitted on: Wed 15 Jul 2020 09:58:09 AM CEST Category: Non

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

URL: Summary: Revert regression in Yacc support, and add Bison support Project: Autoconf Submitted by: haible Submitted on: Tue 14 Jul 2020 09:47:21 PM CEST Category: None

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

URL: Summary: document a problem with AC_EGREP_CPP and AC_EGREP_HEADER Project: Autoconf Submitted by: haible Submitted on: Tue 14 Jul 2020 09:35:10 PM CEST Category: None

Re: [PATCH] regex: Add extra escapes to regular expressions in m4

Hi Eric, > Here's what I'll push tomorrow to > gnulib, if there are no further objections (a doc patch to autoconf is > also needed, but that will be a different reply): A doc patch would push authors of autoconf macros into this double-the-backslashes business, which - as far as I understand - i

Yacc support vs. Bison support

Hi, Up to version 2.69, Autoconf has - good support for Yacc-syntax sources, - mediocre support for Bison-syntax sources. Let me distinguish - Yacc programs, that follow the POSIX specification http://pubs.opengroup.org/onlinepubs/9699919799/utilities/yacc.html , - Bison programs, tha

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

Follow-up Comment #1, sr #109406 (project autoconf): The workaround is to never run 'autoheader' alone. Always run 'autoheader && toouch config.h.in' (and hope that you are not on an NFS mounted volume with significant time differences between NFS server and client). _

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

URL: Summary: autoheader creates config.h.in file with wrong timestamp Project: Autoconf Submitted by: haible Submitted on: Sun 29 Oct 2017 04:45:21 PM CET Category: None

Re: AC_EGREP_CPP and AC_EGREP_HEADER users - beware of recent gcc

Mike Frysinger wrote: > > As you can see, here 1 source line produces up to 4 output lines (ignoring > > the > > line number comment lines). Attempts to use 'grep Version' to find the > > values of > > __GLIBC__ and __GLIBC_VERSION__ don't work any more. > > seems like we be using -P with CPP wh

AC_EGREP_CPP and AC_EGREP_HEADER users - beware of recent gcc

Hi all, Some uses of AC_EGREP_CPP and AC_EGREP_HEADER probably assume that when no continuation lines (backslash-newline) and no multiline macro invocations are involved, each source line produces at most one output line. This is no longer the case with GCC >= 5. Example: === foo.c =

Re: [GNU Autoconf 2.69] testsuite: 231 failed

> How to reproduce: > $ ./configure --host=i686-pc-linux-gnu \ > --prefix=/arch/x86-linux/gnu-inst-autoconf/2.69 \ > CC="gcc -m32 -march=i586" \ > CXX="g++ -m32 -march=i586" \ > FC="gfortran -m32 -march=i586" \ > LDFLAGS="-m32" \

[GNU Autoconf 2.69] testsuite: 231 failed

On openSUSE 12.1, "make check" reports a test failure: 231: configure directories FAILED (base.at:705) How to reproduce: $ ./configure --host=i686-pc-linux-gnu \ --prefix=/arch/x86-linux/gnu-inst-autoconf/2.69 \ CC="gcc -m32 -march=i586" \

Re: Getting AC_PROG_CC_C99

Paul Eggert wrote: > I don't think the autoconf patch would be that easy, as one would > need to handle a mixture of AC_PROG_CC_C99, AC_PROG_CC_C89, and > AC_PROG_CC_STDC calls. Again, I expect the only thing that's > saved us is that people just use AC_PROG_CC_STDC. Hmm, maybe > Autoconf should

Re: Fwd: Getting AC_PROG_CC_C99

Paul Eggert wrote: > The simplest fix would be something like the patch at the end of > this message. > diff --git a/modules/stdarg b/modules/stdarg > > index 84d3e7b..ab3436e 100644 > > --- a/modules/stdarg

Re: system call trace tools

Eric Blake asked: > Does anyone know the HP-UX counterpart to Linux' strace in order to see > what syscalls are in use by the HP-UX shell, and why/where fd 9 is > getting closed? Here's the tools I know of: - Linux, *BSD: strace - MacOS X: dtruss (based on dtrace, need to make it setuid root your

avoid warning in AC_FUNC_STRERROR_R

onftest.c:174: warning: implicit declaration of function 'isalpha' configure:22416: $? = 0 Here's a proposed fix. All systems I know of have . 2011-06-05 Bruno Haible AC_FUNC_STRERROR_R: Avoid gcc warning. * lib/autoconf/functions.m4 (AC_FUNC_STRERROR_R): In

  1   2   3   >