Re: Improve Autoconf MSVC support

On 2024-06-03 16:19, Antonin Décimo wrote: >> I guess you are not using Automake, because both of these problems >> should be solved automatically by Automake. Automake replaces $CC >> with invocations through a wrapper script that knows how to translate >> -l and -o options into MSVC equivalents

Re: Improve Autoconf MSVC support

Hi Antonin, On 2024-06-03 12:05, Antonin Décimo wrote: > Dear maintainers, > > I've listed three little problems I've had using MSVC and Autoconf. > They stem from MSVC not accepting the same parameters from the usual > unix tools. I wonder if these could be fixed. I'm happy to help with > testin

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

On 2024-04-10 16:36, Simon Josefsson wrote: > Is bootstrap intended to be reliable from within a tarball? I thought > the bootstrap script was not included in tarballs because it wasn't > designed to be ran that way, and the way it is designed may not give > expected results. Has this changed, so

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

On 2024-04-09 18:06, Sam James wrote: > Nick poses that a specific combination of tools is what is tested and > anything else invalidates it. But how does this work when building on > a system that was never tested on, or with different flags, or a > different toolchain? > > It's reasonable to say

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

On 2024-04-01 16:43, Guillem Jover wrote: > But if as a downstream distribution I explicitly request everything > to be considered obsolete via --force, then I really do want to get > whatever is in the system instead of in the upstream package. If I distribute a release package, what I have teste

Re: [sr #111014] autoheader doesn't work with AC_DEFINE_UNQUOTED

On 2024-01-30 21:47, anonymous wrote: > If you use AC_DEFINE_UNQUOTED to define symbols whose names are > expanded from variables, autoheader won't emit them to the template > header file. Later when you run configure, these symbols won't get > defined because the matching define/undef line that is

Re: AC_TYPE_LONG_LONG_INT busted in current Autoconf

On 2024-01-16 23:22, Paul Eggert wrote: > Thanks for reporting that bug. I installed the attached on Savannah; please > give it a try. I applied the patch on top of the 2.72 release. You definitely need to also remove the ;; on the previous lines, every shell I try (new and old) now barfs on th

AC_TYPE_LONG_LONG_INT busted in current Autoconf

Hi, In recent versions of Autoconf, AC_TYPE_LONG_LONG_INT (and AC_TYPE_UNSIGNED_LONG_LONG_INT) wrongly indicate that (unsigned) long long is supported on compilers which actually do not support it. Looking at the implementation of AC_TYPE_LONG_LONG_INT, it contains: ac_cv_type_long_long_int=ye

Re: [sr #111007] autoconf 2.72 warning: file 'version.m4' included several times

On 2024-01-13 03:26, Румен Петров wrote: > autoconf 2.72 is first release that prints warning: > configure.ac:2: warning: file 'version.m4' included several times The warning here is erroneous and happens now because Autoconf-2.72's m4sugar.m4 (which is used under the hood basically everywhere) no

Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

On 2023-12-21 19:26, Paul Eggert wrote: > On 2023-12-21 13:19, Zack Weinberg wrote: >> Sorry, I'm with GNU here: failure to report errors on writing to >> stdout is a bug. No excuses will be accepted. > > Agreed. printf commands that silently succeed when they can't do the > requested action are

Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

On 2023-12-21 19:34, Paul Eggert wrote: > ulimit -f 0 > trap "" XFSZ > printf "test" >test || echo failed with status $? > > which issues the following diagnostics on Solaris 10 /bin/sh: > > printf: write error: File too large > failed with status 1 I think you might want to double che

Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

On 2023-12-21 13:48, Zack Weinberg wrote: > and an unsuccessful exit status. I would guess that on your machine > the printf built-in and/or standalone printf executable are not > reporting write errors. I think it is not reasonable to expect any utility to report any kind of error on writes to

Re: [sr #110554] AC_CONFIG_HEADERS doesn't work properly for files with Windows line-endings

On 2023-12-15 11:19, Zack Weinberg wrote: [...] > old non-GNU implementations of awk probably don't support using a > regexp as the third argument to 'split'. (I'm not 100% sure about > this; the gawk manual is usually very good about pointing out > portability issues but in this case it's ambiguo

Re: [sr #110382] In autoconf-2.69d AC_LANG_SOURCE implicitly includes '#include "confdefs.h"'

On 2023-12-08 09:25, Zack Weinberg wrote: > Thinking about this one some more, I see two ways to make confdefs.h > idempotent: > > 1. A conventional "multiple inclusion guard", wrapping the body of the file in > #ifndef ... #endif. This will work on all compilers and regardless of whether > confd

Re: [sr #110846] cross-compilation is not entered when build_alias and host_alias are the same

On 2023-12-07 21:28, Zack Weinberg wrote: Follow-up Comment #1, sr#110846 (group autoconf): We regret the delay in responding to this bug report. I believe this is the same as #110348. The proposal there would make it so you could force a configure script into cross-compilation mode, even when

Re: [GNU Autoconf 2.71] testsuite: 254 255 ... catastrophic failure

On 2023-11-29 14:29, Zack Weinberg wrote: > On Wed, Nov 29, 2023, at 9:32 AM, Dennis Clarke via Bug reports for autoconf > wrote: [...] >> --- ./at_config_vars-state-env-expected 2023-11-29 09:14:04.189405540 -0500 >> +++ ./at_config_vars-state-env.after2023-11-29 09:14:04.189405540 -0500 >> @

Re: m4_ax_check_typedef.m4 fixes

Hi, On 2023-11-11 04:34, stsp wrote: Hi, I've found the m4_ax_check_typedef.m4 script here: http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_typedef.m4 This is the Autoconf list, which despite the confusingly similar name is unrelated to the "Autoconf Arch

Re: AC_PROVIDE{_IFELSE} not documented?

On 18/06/2023, Karl Berry wrote: > Maybe I'm going blind, but it seems that AC_PROVIDE and > AC_PROVIDE_IFELSE are not documented in the Autoconf manual. AC_PROVIDE > is mentioned but not described. AC_PROVIDE_IFELSE is not mentioned. When I reported this many years ago, the response[1] at the t

Re: [sr #110846] cross-compilation is not entered when build_alias and host_alias are the same

On 2023-03-01, anonymous wrote: > This might be the desired use case, but when cross compiling with > systems like buildroot one might have the same architecture on > --build and --host. > > Example: Compile on Apple silicon (aarch64-unknown-linux-gnu) for a Cortex > A75 based system (aarch64-unkn

Re: [sr #110687] AC_C_BIGENDIAN fails when cross-compiling with -std=c11 and -flto

On 2022-07-27, anonymous wrote: > Follow-up Comment #2, sr #110687 (project autoconf): > >> It appears to me that this is an issue with cross compilation and strict > conformance mode (-std=c11), not with -flto. Could you please report what > happens, using the same cross-compilation toolchain, i

Re: Wrong order of preprocessor and compiler flags

On 2022-03-24, Zack Weinberg wrote: > On Thu, Mar 24, 2022, at 11:13 AM, Nick Bowler wrote: >> However, GNU coding standards state that CFLAGS should be the last >> item on compilation commands, so it would appear that this is a case >> where traditional "make&quo

Re: Wrong order of preprocessor and compiler flags

On 2022-03-23, Zack Weinberg wrote: > On Wed, Mar 23, 2022, at 11:31 AM, Evgeny Grin wrote: >> I've found that everywhere in autoconf scripts flags are used like: >> $CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&AS_MESSAGE_LOG_FD >> while automake and libtool use flags in the other order: >> $(CC) $

Re: [sr #110212] Transform pkgdatadir using program-prefix and -suffix

On 2021-07-27, Eric Siegerman wrote: > Follow-up Comment #4, sr #110212 (project autoconf): > > 0 Edit _configure.ac_: In the _AC_INIT()_ call, change the first argument > to > the name you want to use for the subdirectory > 0 Run _autoconf_ (perhaps indirectly, if the package provides an > _autog

Re: autoupdate produces changes for the current ax_* macros from the archive

Hi Dima, On 2021-05-19, dima.pasech...@cs.ox.ac.uk wrote: > what is the procedure for fixing autoconf-2.71-incompatible macros in > the autoconf archive? [...] > For instance, autoupdate provides replacements for > AC_WARNING in ax_compare_version.m4 from > https://www.gnu.org/software/autoconf-a

Re: autoconf-2.71: declaration ordering problem: ac_fn_c_try_run () is defined, but after attempted use

On 2021-04-01, Ondrej Dubaj wrote: > experiencing configure problem > > ./configure: line 18777: ac_fn_c_try_run: command not found > > It seems that CMU_HAVE_OPENSSL brings CMU_FIND_LIB_SUBDIR brings > AC_CHECK_SIZEOF(long) ... that brings the use of *check_int and that > brings the use of ac_fn_

Re: autoupdate: AU_ALIAS shouldn't affect itself

On 2021-01-26, egall--- via Bug reports for autoconf wrote: > Say I have an M4 macro file with an AU_ALIAS usage in it like this: > > AU_ALIAS([BNV_HAVE_QT], [AX_HAVE_QT]) > > If I run autoupdate on this file, that will become: > > AU_ALIAS([AX_HAVE_QT], [AX_HAVE_QT]) > > This seems pointless, as

Re: realpath fails on MacOS 11.1 (big sur), with bugfix

On 2021-01-16, Michael Labbé wrote: > realpath() is failing to compile for me on MacOS 11.1 on an Apple M1 Mac. I > encountered this when building GNU Global Tags from the most recent source > archive at global-6.6.5.tar.gz > . > > This is due to an

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

On 2020-12-10, Karl Berry wrote: > When a longstanding core existing feature (AC_PROG_CC) is changed in a > backward-incompatible way, a way to get the heretofore standard behavior > feels more like a bug fix than a feature request to me. For that matter, it > feels > like a new macro or option

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

On 2020-10-22, Zack Weinberg wrote: > I acknowledge that requiring double-quotation of AC_INIT arguments > when they contain characters significant to M4 _should_ work; however, > it did not work in my tests (which were not exactly the same as the > above; see the "AC_INIT with unusual version str

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

On 2020-10-22, Nick Bowler wrote: > On 22/10/2020, Zack Weinberg wrote: >> On Thu, Oct 22, 2020 at 11:53 AM Nick Bowler wrote: >>> On 2020-10-22, Zack Weinberg wrote: >>> > On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert >>> > wrote: >>>

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

On 22/10/2020, Zack Weinberg wrote: > On Thu, Oct 22, 2020 at 11:53 AM Nick Bowler wrote: >> On 2020-10-22, Zack Weinberg wrote: >> > On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert >> > wrote: >> >> >> >> On 10/21/20 6:15 AM, Zack Weinberg wrot

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

On 2020-10-22, Zack Weinberg wrote: > On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert wrote: >> >> 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

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

On 2020-10-21, Zack Weinberg wrote: > On Tue, Oct 20, 2020 at 4:57 PM Nick Bowler wrote: >> Note: the change you report is introduced by Zack's fix for related >> AC_INIT quoting regressions. This patch is not included in 2.69c (or >> even on git master), but does

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

Hi, On 2020-10-20, Sergei Trofimovich wrote: > Initial bug is reported as autoconf failure on ghc-8.8.4: > https://bugs.gentoo.org/750191 > There autconf 2.69 works, 2.69c does not. Note: the change you report is introduced by Zack's fix for related AC_INIT quoting regressions. This patch i

Re: [sr #110318] autoreconf: support libtoolize being named glibtoolize

On 2020-04-29, Zack Weinberg wrote: > 2.61 was a long time ago. I'm wondering if Gentoo still ships > 'glibtoolize' and not 'libtoolize'. If it doesn't, this change is > only weakly motivated. Today at least, Gentoo certainly does not install a "glibtoolize" nor does it install a patched autore

Re: [sr #110286] Make it possible to request a specific (non-latest) version of a language standard

On 2020-07-27, Zack Weinberg wrote: > URL: > > > Summary: Make it possible to request a specific > (non-latest) > version of a language standard > Project: Autoconf > Submitted by: zackw > Submit

Re: [sr #110271] libSDL2 fails with autoconf 2.70

On 2020-07-16, Ross Burton wrote: [...]] > libSDL2 fails to configure with autoconf 2.70 but works with 2.69: > > | checking for size_t... yes > | checking for M_PI in math.h... ../SDL2-2.0.12/configure: line 13202: CPP: > command not found > | checking how to run the C preprocessor... gcc -E > |

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

On 2020-04-13, Paul Eggert wrote: > I just checked, and GNU Make uses high-resolution file timestamps when > available, and considers a file to be up-to-date if it has exactly the same > timestamp as its dependency. I suspect that this is because Makefile rules > like > this: > > a: b > cp -

Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master

On 2020-03-24, Ross Burton wrote: > As to why this is not broken with 2.69, I think I have a theory. > > If I build e.g. acl with both 2.69 and master, it's notable that 2.69 > has these lines in the output that do not exist in master: > >> checking how to run the C preprocessor... gcc -E >> chec

Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master

Hi Ross, On 2020-03-24, Ross Burton wrote: [...] > AC_CHECK_FUNC(statvfs,[HAVE_STATVFS=yes]) > dnl Arg, linux and bsd put their statfs function in different places > if test x"$HAVE_STATVFS" != x"yes"; then >AC_EGREP_HEADER(statfs,sys/vfs.h,[AC_DEFINE(HAVE_VFS_H)],[ > > AC_EGREP_HEADER(statfs

Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master

On 2020-03-23, Ross Burton wrote: > apt 1.2.31 builds fine with autoconf 2.69. With git master: > > | checking for h_errno... configure: error: "not found." > > That code is: > > dnl HP-UX needs -d_XOPEN_SOURCE_EXTENDED for h_errno > AC_MSG_CHECKING(for h_errno) > AC_EGREP_HEADER(h_errno, netdb.h

Re: [sr #110213] curl fails with autoconf master

On 20/03/2020, Ross Burton wrote: > URL: > > > Summary: curl fails with autoconf master > Project: Autoconf > Submitted by: rossburton > Submitted on: Fri 20 Mar 2020 03:36:28 PM UTC >

Re: autoconf: AC_SEARCH_LIBS with AC_LANG([C++]) broken when using gcc 8

On 1/17/19, Paul Gevers wrote: > On 14-01-2019 11:57, Matthias Klose wrote: >> On 12.01.19 21:37, Chaim Zax wrote: >>> Because autoconf can be used outside a Debian environment this solution >>> might not work for everyone. Perhaps the AC_SEARCH_LIBS function should >>> be extended so function arg

Re: Potential bug in AC_CONFIG_SRCDIR

Hi Michael, On 2019-01-07, Michael Cress wrote: > I am observing some strange behavior ( see comments in snippet ) with the > AC_CONFIG_SRCDIR macro when using the configure.ac snippet below. [...] > #Define a subdirectory which contains the source files ( a separate Git repo > ) > DCMSGSRCDIR=Doc

Re: Setting a default value for an AC_ARG_VAR

On 12/16/18, Reuben Thomas wrote: > On Fri, 14 Dec 2018 at 14:51, Nick Bowler wrote: > >> >> If you want to set a value to a variable only if the variable is >> unset, a typical way to do that in shell programming is: >> >> : "${FOO=value-if-unset}&q

Re: Setting a default value for an AC_ARG_VAR

On 12/14/18, Reuben Thomas wrote: > What's the right way to do this? I currently have: > > AC_ARG_VAR([WORD_SIZE], > [value of WORD_SIZE register [default: sizeof(long)]]) > if "$ac_cv_env_WORD_SIZE_set" != set; then > AC_CHECK_SIZEOF([long]) > ac_cv_env_WORD_SIZE_value=SIZEOF_LONG > fi > >

Re: autoconf test for `ls -t` doesn't account for envar QUOTING_STYLE

On 10/23/18, Cathy Garrett wrote: > I've found a bug in autoconf related to the ls command's environment > variable QUOTING_STYLE. > > By having QUOTING_STYLE=c in my environment, the following stanza fails. > The reason for the failure is in the code [...] > set X `ls -Lt "$srcdir/configure

Re: missing backslash escaping in AC_TRY_EVAL yields binary data in config.log with dash

On 10/2/18, Vincent Lefevre wrote: > I originally reported this bug in libtool: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21309 > > but this actually seems to be a bug in AC_TRY_EVAL (or another macro > it uses). AC_TRY_EVAL is not documented in the Autoconf manual. Drilling into the A

Re: autoconf doesn't escape sed metacharacters in paths

On 6/18/18, Quasi Computational wrote: > Reproduction: > > ``` > $ mkdir '\9' > $ cd '\9' > $ git clone https://github.com/haskell/network > $ cd network > $ git checkout 7e3f16d57b8745ef12cec8c9164bb91eeac90b5b # known-to-fail > commit > $ autoconf > $ ./configure > ``` > > This fails for me wit

Re: autoreconf uses aclocal even when not needed

Hello, On 3/22/17, Max Horn wrote: [snip] > $ autoreconf -vif --no-recursive -I cnf/m4 . > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal -I cnf/m4 --output=aclocal.m4t > Can't exec "aclocal": No such file or directory at > /sw/sha

Re: Broken example in autoconf manual

Hello, On 2017-03-16, Max Horn wrote: > on > https://www.gnu.org/software/autoconf/manual/autoconf.html#Using-System-Type > > this example is given: > > case $host in >alpha*-*-*) AC_CONFIG_LINKS([dither.c:alpha/dither.c]) ;; >powerpc*-*-*) AC_CONFIG_LINKS([dither.c:powerpc

Re: Documentation of AC_ARG_WITH

Hello, On 2/21/17, Reuben Thomas wrote: > In the first example for AC_ARG_WITH, there's an "if test…fi" block: > > if test "x$with_readline" != xcheck; then >AC_MSG_FAILURE( > [--with-readline was given, but test for readline failed]) > fi > > Is there some reason why th

Re: bug#20733: coreutils build problem

On 2015-06-04 14:41 -0600, Eric Blake wrote: > On 06/04/2015 02:17 PM, Nick Bowler wrote: > > Do these problematic shells properly handle: > > > > for arg > > do > > ... > > done > > > > when $# is 0? > > Yes; all shells do.

Re: bug#20733: coreutils build problem

I suppose that might be hard to do in this /particular/ case, as it looks like the error is coming from a make rule. The Autoconf manual quite emphatically says to avoid 'for arg; do ...' by using a newline instead of a semicolon, a feat which is not easily done in make rules. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: ./configure --help

So it's best to only describe the function of --enable-foo/--with-foo, with some text to state the default behaviour. The curl help output does indeed seem needlessly excessive. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

mainly for style reasons... > +if test -x "$dirname"/'@grep@'; then > + PATH="$dirname:$PATH" > + grep='@grep@' > fi;; > esac > exec $grep @option@ "$@" Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Faillure to autogenerate file on hpux

look like you need $^, or even basename. I think you can just replace the string (unfortunately, you'd need to see the rest of the Makefile to be sure): $(notdir $^) with: quantum.pm and it will work just as well, and be portable. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Re-execute with the "correct" make implementation

ill happily fork off two independent make instances in parallel: one running "gmake all" and one running "gmake install". The result will probably be catastrophic. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Making variably-named .in files work with config.status

ted): AC_CONFIG_FILES(m4_defn([AC_PACKAGE_NAME])[.rockspec]) Note the (lack of) quoting around the call to m4_defn: this is because m4_defn produces an appropriately quoted string and we actually want that macro to be expanded before passing the result to AC_CONFIG_FILES. But the rest of the ar

AC_SUBST is temperamental in expanding its first argument.

Hi folks, I noticed today (using Autoconf 2.69, although the problem is still present in Git) that when the first argument of AC_SUBST contains macro names, the behaviour is very odd. Consider the following: % cat >configure.ac <<'EOF' AC_INIT([test], [0]) m4_define([FOO], [baz]) AC_SUBST([FOO]

Typo in shell substitution example in autoconf manual.

#x27;\''}\\"; echo "${a-$t}"' > b c"'}\ I had a double take upon reading this. I think the output for all three of those example commands should read a b"'}\ rather than b c"'}\ as it appears in the manual. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)