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

[Bruno Haible]

Hi,

The AC_PROG_OBJC macro does not work out-of-the-box on RHEL 9, AlmaLinux 9,
etc. because on these systems, the /usr/bin/gcc program does not support
Objective-C [1]. There is a package in EPEL 9 (the "community"-driven
package repository for RHEL-based distributions) that contains the GNU
Objective-C compiler [2] (provided by Robert Scheck [3]), under the name
/usr/bin/gobjc.

However, this is still not sufficient for packages that invoke AC_PROG_OBJC
without arguments, because the configure script will find the 'gcc' program
(from its list of tries: gcc objcc objc cc CC clang), and the gcc program
does not support Objective-C even after the EPEL 9 package is installed.

Two workarounds are possible:

  a) The package maintainer can use
   AC_PROG_OBJC([gobjc gcc objcc objc cc CC clang])
 instead of
   AC_PROG_OBJC

  b) The user can set the OBJC environment variable to 'gobjc'
 before running configure.

However, it would be better if this worked out-of-the-box,
because RHEL 9 and compatible systems are not just some random
system like Haiku or AIX; these distros are some of the most
important distributions of GNU 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 Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Tue, 16 Jul 2024 04:59:23 +0200
Subject: [PATCH] Make AC_PROG_OBJC work out-of-the-box on RHEL 9 and
 compatible systems.

* lib/autoconf/c.m4 (AC_PROG_OBJC): Search for gobjc before gcc.
* NEWS: Mention the change.
---
 NEWS  |  3 +++
 lib/autoconf/c.m4 | 13 -
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/NEWS b/NEWS
index bca11391..e0d35099 100644
--- a/NEWS
+++ b/NEWS
@@ -28,6 +28,9 @@ GNU Autoconf NEWS - User visible changes.
   The autom4te, autoscan and ifnames programs now recognize the two
   preprocessor directives, which were introduced in C23 and C++23.
 
+*** AC_PROG_OBJC now finds the GNU Objective-C compiler, as packaged in
+  EPEL 9, by default, without the user having to set the OBJC variable.
+
 * Noteworthy changes in release 2.72 (2023-12-22) [release]
 
 ** Backward incompatibilities
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index 456a6ba7..1727961e 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -854,10 +854,13 @@ AC_DEFUN([AC_LANG_COMPILER(Objective C)],
 # search for (if not specified, a default list is used).  This just gives
 # the user an opportunity to specify an alternative search list for the
 # Objective C compiler.
-# objcc StepStone Objective-C compiler (also "standard" name for OBJC)
-# objc  David Stes' POC.  If you installed this, you likely want it.
-# ccNative C compiler (for instance, Apple).
-# CCYou never know.
+# gobjc  GNU Objective-C compiler packaged in EPEL (for systems where gcc
+#does not support Objective-C)
+# gccGNU Objective-C compiler on most systems
+# objcc  StepStone Objective-C compiler (also "standard" name for OBJC)
+# objc   David Stes' POC.  If you installed this, you likely want it.
+# cc Native C compiler (for instance, Apple).
+# CC You never know.
 AN_MAKEVAR([OBJC],  [AC_PROG_OBJC])
 AN_PROGRAM([objcc],  [AC_PROG_OBJC])
 AN_PROGRAM([objc],  [AC_PROG_OBJC])
@@ -870,7 +873,7 @@ _AC_ARG_VAR_LIBS()dnl
 _AC_ARG_VAR_CPPFLAGS()dnl
 _AC_ARG_VAR_PRECIOUS([OBJC])dnl
 AC_CHECK_TOOLS(OBJC,
-	   [m4_default([$1], [gcc objcc objc cc CC clang])],
+	   [m4_default([$1], [gobjc gcc objcc objc cc CC clang])],
 	   gcc)
 # Provide some information about the compiler.
 _AS_ECHO_LOG([checking for _AC_LANG compiler version])
-- 
2.34.1

Re: ac_cv_sys_largefile_opts undocumented?

[Bruno Haible]

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"], [],
>   dnl otherwise it is a compiler flag
>   [LARGEFILECFLAGS="$ac_cv_sys_largefile_opts"]
>   )
> 
> which are unnecessarily complicated.

All ac_cv_* variables, and in fact all *_cv_* variables, are designed to
contain the answer to a
  checking for ...
output line, in a way that is both machine-parseable and human-readable.

As a consequence:
  - Its values look sometimes odd (e.g. 'no (bad O_NOATIME, O_NOFOLLOW)'.
  - Its values are not stable over time and therefore *cannot be documented*.

The entities which can often be documented are AC_SUBSTed variables and
the C/C++ preprocessor macro definitions (AC_DEFINE).

If there is the need for an Autoconf macro to expose more details, in a
documented way, it should be done through a new AC_SUBSTed variable or
a new AC_DEFINE.

Bruno

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

[Bruno Haible]

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]".

But the GPL does not require that the corresponding sources be included
in the *same tarball*.

When a distro distributes binary packages, they don't include the source
code in the same binary .rpm or binary .tar.xz. All they do is to provide
the source code in a location that is straightforward to find.

The same rights hold for upstream package maintainers: When they produce
tarballs, that include a "binary" configure and generated .c files, it is
sufficient that the source code (*.m4 files and .y and .l files) are in
the git repository or submodules, and that the git repository is straight-
forward to find.

Bruno

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

[Bruno Haible]

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,
>  >* It shows [...]
> 
> FWIW: especially the downstream builds of the 'coreutils' package have been
> using 'autoreconf -fi' for a long time, because the upstream tools do not
> have full I18N support, and the large I18N patch is in use e.g. at Fedora,
> openSUSE and Debian probably since >15 years.

Sure, if downstream applies a patch that modifies bootstrap.conf, they need
to rerun 'bootstrap'. That goes without saying. I hope downstream then also
runs "make check".

Bruno

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

[Bruno Haible]

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/automake/libtool or whatever,
> >> then this you have invalidated any and all release testing.
> >
> > +1
> >
> > 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,
> >   * It shows no respect for the QA work that the upstream developers have
> > put in.
> ...
> Nick poses that a specific combination of tools is what is tested and
> anything else invalidates it.

Correct. When an upstream developer/tester has tested a tarball in N
situations, then that tarball is what - he can guarantee - works. The
more changes a distro applies, the more they do so on their own risk.

> But how does this work when building on a
> system that was never tested on, or with different flags, or a different
> toolchain?

The interface of GNU 'configure' [1][2] accommodates for these cases.
In most of these cases, it is not needed to rebuild 'configure'. Just
set CC, CFLAGS, LDFLAGS etc.
  - For other systems: see [3].
  - System that is still in development: Replace config.guess, config.sub,
and potentially config.rpath with modified variants.
  - Different flags: That's what CFLAGS, CXXFLAGS are for.
  - Different compiler: E.g. clang on Ubuntu 22.04
CC="/inst-clang/17.0.4/bin/clang -Wl,-rpath,/inst-clang/17.0.4/lib"
CXX="/inst-clang/17.0.4/bin/clang++ -I/usr/include/c++/11 
-I/usr/include/x86_64-linux-gnu/c++/11 -L/usr/lib/gcc/x86_64-linux-gnu/11 
-Wl,-rpath,/inst-clang/17.0.4/lib"
  - Different linker: E.g. to link with 'mold' instead of 'ld',
create a directory /alternative-ld/with-mold that contains a symlink
ld -> /.../bin/mold
and use CC="gcc -B/alternative-ld/with-mold".

On exotic systems with non-ELF binary format, modifying libtool.m4 is needed.
But most distros are not in this situation; they use the glibc or musl dynamic
loader, hence they don't need libtool.m4 changes.

> It also has value in the context of software which is no longer
> maintained but needs to work on newer systems.

Granted; that's a different category of situation. Here a distro will
probably not only need to change *.m4 files but also *.c files. And
hopefully submit the changes upstream.

> We don't apply this rule to anything else -- you've never rejected a
> report from me because I have a newer version of a library installed
> like openssl or similar. Why is this different?

As an upstream maintainer, I have chosen (or, well, GNU has chosen for me,
even before I was present) to give *tarballs* to my users, not git
repositories. The main differences are that

  - tarballs contain some generated files for which we want to spare
the user the need to install special tools and get familiar with
them (code generators, doc formatters [texlive, doxygen, ...] etc.)

  - tarballs contain source code from other packages (git submodule,
parts of gnulib, etc.)

  - tarballs contain localizations, which are maintained elsewhere than
in the git repository (e.g. in translationproject.org or weblate
instances).

Experience has shown that this interface (tarballs with configure
script) allows for relatively effective support.

There are an entire bunch of questions from users of a git repository
(from "can you please commit the formatted documentation into git?"
over "how to I pull in the submodules?" to "why do I get this error
from flex?") that are obsoleted by this interface.

Also, too often people have reported problems with older versions of
the tools. I mean, we are at Automake 1.16.5, and if someone wants
to rebuild my package with Automake 1.13.4 because that's what his
distro is carrying, and they encounter problems, it is just a waste
of upstream developer's time. Old bugs in old versions of the tools
have been fixed. As an upstream maintainer, I don't want to support
  - different versions of Automake,
  - different versions of Bison,
  - different versions of texinfo,
  - different versionf of groff,
  - etc.
I have enough work supporting
  - different versions of the OS (glibc, Cygwin, etc.),
  - different versions of GNU make,
  - different versions of gcc and clang,
  - different versions of packages with optional support (--with-* options),
  - ...
Keep the test matrix small!

Bruno

[1] https://www.gnu.org/prep/standards/html_node/Configuration.html
[2] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/Preset-Output-Variables.html
[3] https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration

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

[Bruno Haible]

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
where the last paragraph says:

  "Finally, note that the --force option of aclocal has absolutely
   no effect on the files installed by --install. For instance, if you
   have modified your local macros, do not expect --install --force to
   replace the local macros by their system-wide versions. If you want
   to do so, simply erase the local macros you want to revert, and run
   ‘aclocal --install’."

Bruno

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

[Bruno Haible]

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 testing.

+1

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,
  * It shows no respect for the QA work that the upstream developers have
put in.
  * It increases the number of bug reports that reach upstream and yet
are caused by the distro.
  * In the long run, the upstream maintainers will be less willing to
handle bug reports from users of this distro.

Bruno

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

[Bruno Haible]

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 will
not help. [1]

Therefore it is more reliable to curate the xz releases at their
download locations and in the distros.

Bruno

[1] https://www.gnu.org/software/automake/manual/html_node/Serials.html

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

[Bruno Haible]

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 like «autoreconf -f -i» (that is run in Debian as part of
> > dh-autoreconf via dh) still seems to take the serial into account,
> > which was bumped in the tampered .m4 file. If either the gettext.m4
> > had gotten downgraded (to the version currently in Debian, which would
> > not have pulled the tampered build-to-host.m4), or once Debian upgrades
> > gettext, the build-to-host.m4 would get downgraded to the upstream
> > clean version, then the hook would have been disabled and the backdoor
> > would be inert. (Of course at that point the malicious actor would
> > have found another way to hook into the build system, but the less
> > avenues there are the better.)
> > 
> > I've tried to search the list and checked for old bug reports on the
> > debbugs.gnu.org site, but didn't notice anything. To me this looks like
> > a very unexpected behavior, but it's not clear whether this is intentional
> > or a bug. In any case regardless of either position, it would be good to
> > improve this (either by fixing --force to force things even if
> > downgrading, or otherwise perhaps to add a new option to really force
> > everything).
> > 
> > [A] 
> > Longish mail, search for "try to go in detail" for the analysis.

The 'serial' number in *.m4 files exists precisely so that tools like
'aclocal --install' or (as you say) 'autoreconf -f -i' can avoid
overwriting newer .m4 files with older versions.

I don't know exactly about the situations in which this happens. But
your investigations shed enough light on it. You write:
  "If either the gettext.m4
   had gotten downgraded (to the version currently in Debian, which would
   not have pulled the tampered build-to-host.m4), or once Debian upgrades
   gettext, the build-to-host.m4 would get downgraded to the upstream
   clean version"

The situation is:
  - Debian stable is still on gettext 0.21, which comes with
  gettext.m4 serial 71
  - gettext-0.22 comes with
  gettext.m4 serial 77
which depends on build-to-host.m4.
Assume furthermore that a package P relies on gettext (via AM_GNU_GETTEXT),
and the user has installed gettext-0.22 or newer. And they run
  $ autoreconf
which invokes autopoint, which installs the gettext.m4.

If, in this situation, the newer .m4 file would not prevail, Debian's
old gettext.m4 would take precedence. This would mean that new features
from new gettext releases would not land in the users' hands; they
would be blocked by Debian, for the time the user uses this distro+version
(often 4 or 5 years).

Worse, this would also hold for Red Hat distro releases, which typically
are not 4-5 years, but 10-12 years behind the newest release. It would
mean that *for 10 years*, packages P could not make use of new features
(and bug fixes) that were added in GNU gettext upstream.

This is the problem that the 'serial' number annotation fixes.

It may be unexpected to you, but it is very much intended.

And if aclocal's preference was the other way around, always favouring
the smaller serial number, then the attacker would not have picked
'serial 30' but 'serial 1', in order to override the distro's version.

> My understanding is that the use of serial numbers in .m4 snippets was
> intentional in gnulib (more or less where the practice originated),
> but only because gnulib prefers a linear history (everything is
> monotonically increasing, no forks for the serial number to diverge
> on).

The history is mostly linear, yes. There is a bit of nonlinearity
  - because gettext.m4 gets copied from gettext to gnulib and/or
from gnulib to gettext,
  - because gettext has a release branch,
  - because gnulib has stable branches,
but all in all, it's linear.

> In light of this weekend's mess, Bruno may have more ideas about
> how to prevent his files from being turned into backdoor delivery
> mechanisms in the future.

I gave my opinion here:
  https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00422.html
  https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00421.html

Basically I think that an attacker who is clever enough to bypass the
RELRO protection by using IFUNC, knowing that IFUNC gets processed
_before_ the GOT or PLT pages are made read-only, — such an attacker
will also find ways to conceal their malware triggers, regardless of
any simple measures at the source code level that we might invent.

Bruno

Re: Autoconf documentation link broken

[Bruno Haible]

Paul Eggert wrote:
> Thanks, it should be working now.

Yes, it works now. Thanks!

Bruno

Autoconf documentation link broken

[Bruno Haible]

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

[Bruno Haible]

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

testsuite: command line was:
  $ tests/testsuite -C tests MAKE=gmake

## -- ##
## ChangeLog. ##
## -- ##

| 2023-12-22  Zack Weinberg  
| 
| 	Finalize NEWS for release 2.72.
| 	Since 2.72[abcde] did not get widely used, squash all the NEWS entries
| 	since 2.71 together, and delete things that were only of interest to
| 	people going from a,b,c to d to e.  Finalize the release date.
| 
| 2023-12-22  Zack Weinberg  
| 
| 	Save/restore AC_LANG setting in AC_PROG_CC_C_O.

## - ##
## Platform. ##
## - ##

hostname = openbsd74.fritz.box
uname -m = amd64
uname -r = 7.4
uname -s = OpenBSD
uname -v = GENERIC#1336

/usr/bin/uname -p = amd64
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = OpenBSD.amd64
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/bruno/autoconf-2.72/build/tests/
PATH: /home/bruno/autoconf-2.72/tests/
PATH: /home/bruno/autoconf-2.72/build/tests/
PATH: /home/bruno/bin/
PATH: /bin/
PATH: /sbin/
PATH: /usr/bin/
PATH: /usr/sbin/
PATH: /usr/local/bin/
PATH: /usr/local/sbin/

testsuite: atconfig:
| # Configurable variable values for building test suites.
| # Generated by ./config.status.
| # Copyright (C) 2023 Free Software Foundation, Inc.
| 
| # The test suite will define top_srcdir=/../.. etc.
| at_testdir='tests'
| abs_builddir='/home/bruno/autoconf-2.72/build/tests'
| at_srcdir='../../tests'
| abs_srcdir='/home/bruno/autoconf-2.72/build/../tests'
| at_top_srcdir='../..'
| abs_top_srcdir='/home/bruno/autoconf-2.72/build/..'
| at_top_build_prefix='../'
| abs_top_builddir='/home/bruno/autoconf-2.72/build'
| 
| # Backward compatibility with Autotest <= 2.59b:
| at_top_builddir=$at_top_build_prefix
| 
| AUTOTEST_PATH='tests'
| 
| SHELL=${CONFIG_SHELL-'/bin/sh'}

testsuite: atlocal:
| # -*- shell-script -*-
| # tests/atlocal.  Generated from atlocal.in by configure.
| # Configurable variable values for Autoconf test suite.
| 
| # Copyright (C) 2000-2001, 2005, 2008-2017, 2020-2023 Free Software
| # Foundation, Inc.
| #
| # This program is free software: you can redistribute it and/or modify
| # it under the terms of the GNU General Public License as published by
| # the Free Software Foundation, either version 3 of the License, or
| # (at your option) any later version.
| #
| # This program is distributed in the hope that it will be useful,
| # but WITHOUT ANY WARRANTY; without even the implied warranty of
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
| # GNU General Public License for more details.
| #
| # You should have received a copy of the GNU General Public License
| # along with this program.  If not, see .
| 
| AWK='awk'
| EGREP='/usr/bin/grep -E'
| GREP='/usr/bin/grep'
| M4='/home/bruno/bin/m4'
| PERL='/usr/bin/perl'
| SED='/usr/bin/sed'
| 
| # We need to know if sh -n is ok.
| SHELL_N='bash'
| 
| # Check whether the underlying system can manage some unusual
| # symbols in file names.
| if test -z ''; then
|   func_sanitize_file_name () { echo "$@"; }
| else
|   func_sanitize_file_name () { echo "$@" | tr -d ''; }
| fi
| 
| # Can we create directories with trailing whitespace in their names?
| ac_cv_dir_trailing_space='yes'
| if test "$ac_cv_dir_trailing_space" = yes; then
|   func_sanitize_dir_name () { echo "$@"; }
| else
|   func_sanitize_dir_name () { echo "$@" | sed 's/  *$//'; }
| fi
| 
| # AUTOM4TE might be set in the environment.  Override it here so that
| # direct aclocal invocations also use it.
| AUTOM4TE=autom4te
| export AUTOM4TE

## --- ##
## System supplied programs that we depend on. ##
## --- ##

# m4 is /home/bruno/bin/m4
/home/bruno/bin/m4 --version
m4 (GNU M4) 2023-11-25
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Ren'e Seindal.

# perl is /usr/bin/perl
/usr/bin/perl --version

This is perl 5, version 36, subversion 1 (v5.36.1) built for amd64-openbsd

Copyright 1987-2023, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at https://www.perl.org/, 

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

[Bruno Haible]

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 attached the testsuite.log.



testsuite.log.gz
Description: application/gzip

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

[Bruno Haible]

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, autopoint, and
gnulib-tool. This creates interdependencies between GNU gettext and GNU
gnulib, that fortunately are bearable because GNU gnulib changes are effective
immediately - no releases.

If we were to add a fourth tool (autoreconf), we would also have
interdependencies between GNU autoconf and GNU gettext. Since GNU autoconf
tends to have releases quite infrequently, roughly once every 3 years on
average, this would mean that some aspects of GNU gettext could be blocked for
several years. (There are also already interdependencies between GNU automake
and GNU gettext. We have been lucky that this affects only a warning and
nothing is blocked.)

It is better if this bug does not get fixed - this affects few users - than
that the development of GNU gettext be partially blocked for years.

The proper way to fix this would be for 'autoreconf' to invoke some program
(or shell script) that GNU gettext has installed. So that GNU gettext may
evolve even if there are no new GNU autoconf releases for N years. Much like
bash does with the bash completions: bash does not include completion logic
for a multitude of package, but rather it has a mechanism through which
packages can install their completion logic.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: autoconf-2.72d on other platforms

[Bruno Haible]

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

[Bruno Haible]

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

[Bruno Haible]

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: torture.at:189 AC_CONFIG_FILES, HEADERS, LINKS and COMMANDS
 445: semantics.at:1255  AC_PROG_LEX with noyywrap
 446: semantics.at:1257  AC_PROG_LEX with yywrap
 510: acprograms.at:22   AC_DECL_YYTEXT



testsuite.log.gz
Description: application/gzip

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

[Bruno Haible]

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
> stat -f .
> 
> executed from the subdirectory tests/testsuite.dir/011 of your build 
> directory?
> This is the output I get, on a machine where this test reliably passes:
> 
> $ find . -printf '%T+\t%P\n' | sort
> 2023-12-01+08:27:35.5911556670configure.ac
> 2023-12-01+08:27:35.5921556740.autom4te.cfg
> 2023-12-01+08:27:37.7141689360autom4te.cache/output.0
> 2023-12-01+08:27:37.7141689360autom4te.cache/traces.0
> 2023-12-01+08:27:37.7151689420autom4te.cache
> 2023-12-01+08:27:37.7201689730configure
> 2023-12-01+08:27:39.8531823020autom4te.cache/requests
> 2023-12-01+08:27:39.8561823210stderr-raw
> 2023-12-01+08:27:39.8641823710
> 2023-12-01+08:27:39.8641823710run
> 2023-12-01+08:27:39.8641823710testsuite.log
> 
> $ stat -f .
>   File: "."
> ID: fd0b Namelen: 255 Type: xfs
> Block size: 4096   Fundamental block size: 4096
> Blocks: Total: 976136003  Free: 363784939  Available: 363784939
> Inodes: Total: 390645120  Free: 385383287

$ find . -printf '%T+\t%P\n' | sort
2023-12-01+06:44:01.1092978040  configure.ac
2023-12-01+06:44:01.1152978320  .autom4te.cfg
2023-12-01+06:44:03.2803078610  autom4te.cache
2023-12-01+06:44:03.2803078610  autom4te.cache/output.0
2023-12-01+06:44:03.2803078610  autom4te.cache/traces.0
2023-12-01+06:44:03.2863078890  configure~
2023-12-01+06:44:03.2893079030  stderr-raw
2023-12-01+06:44:05.4383178570  configure
2023-12-01+06:44:05.4393178610  autom4te.cache/requests
2023-12-01+06:44:05.4423178750  stderr
2023-12-01+06:44:05.4453178890
2023-12-01+06:44:05.4453178890  run
2023-12-01+06:44:05.4453178890  testsuite.log

$ stat -f .
  File: "."
ID: 6fae53cfbfa55de7 Namelen: 255 Type: ext2/ext3
Block size: 4096   Fundamental block size: 4096
Blocks: Total: 2589588Free: 660900 Available: 524427
Inodes: Total: 662256 Free: 419686

$ mount | grep /dev/sda1
/dev/sda1 on / type ext4 (rw,relatime,seclabel)

Bruno

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

[Bruno Haible]

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

| 2023-11-30  Zack Weinberg  
| 
| 	Release 2.72d [beta]
| 	Revise all NEWS entries since 2.71 for clarity.  Add an entry
| 	to the compatibility section about the macros that no longer
| 	have AC_PROG_{EGREP,CPP} as a side effect.
| 
| 	make fetch
| 
| 2023-11-26  Paul Eggert  

## - ##
## Platform. ##
## - ##

hostname = centos8
uname -m = x86_64
uname -r = 4.18.0-80.7.1.el8_0.x86_64
uname -s = Linux
uname -v = #1 SMP Sat Aug 3 15:14:00 UTC 2019

/usr/bin/uname -p = x86_64
/bin/uname -X = unknown

/bin/arch  = x86_64
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/bruno/autoconf-2.72d/build-64/tests/
PATH: /home/bruno/autoconf-2.72d/tests/
PATH: /home/bruno/autoconf-2.72d/build-64/tests/
PATH: /home/bruno/inst-x86_64-64/bin/
PATH: /usr/share/Modules/bin/
PATH: /usr/local/bin/
PATH: /usr/local/sbin/
PATH: /usr/bin/
PATH: /usr/sbin/

testsuite: atconfig:
| # Configurable variable values for building test suites.
| # Generated by ./config.status.
| # Copyright (C) 2023 Free Software Foundation, Inc.
| 
| # The test suite will define top_srcdir=/../.. etc.
| at_testdir='tests'
| abs_builddir='/home/bruno/autoconf-2.72d/build-64/tests'
| at_srcdir='../../tests'
| abs_srcdir='/home/bruno/autoconf-2.72d/build-64/../tests'
| at_top_srcdir='../..'
| abs_top_srcdir='/home/bruno/autoconf-2.72d/build-64/..'
| at_top_build_prefix='../'
| abs_top_builddir='/home/bruno/autoconf-2.72d/build-64'
| 
| # Backward compatibility with Autotest <= 2.59b:
| at_top_builddir=$at_top_build_prefix
| 
| AUTOTEST_PATH='tests'
| 
| SHELL=${CONFIG_SHELL-'/bin/sh'}

testsuite: atlocal:
| # -*- shell-script -*-
| # tests/atlocal.  Generated from atlocal.in by configure.
| # Configurable variable values for Autoconf test suite.
| 
| # Copyright (C) 2000-2001, 2005, 2008-2017, 2020-2023 Free Software
| # Foundation, Inc.
| #
| # This program is free software: you can redistribute it and/or modify
| # it under the terms of the GNU General Public License as published by
| # the Free Software Foundation, either version 3 of the License, or
| # (at your option) any later version.
| #
| # This program is distributed in the hope that it will be useful,
| # but WITHOUT ANY WARRANTY; without even the implied warranty of
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
| # GNU General Public License for more details.
| #
| # You should have received a copy of the GNU General Public License
| # along with this program.  If not, see .
| 
| AWK='gawk'
| EGREP='/usr/bin/grep -E'
| GREP='/usr/bin/grep'
| M4='/usr/bin/m4'
| PERL='/usr/bin/perl'
| SED='/usr/bin/sed'
| 
| # We need to know if sh -n is ok.
| SHELL_N='/bin/sh'
| 
| # Check whether the underlying system can manage some unusual
| # symbols in file names.
| if test -z ''; then
|   func_sanitize_file_name () { echo "$@"; }
| else
|   func_sanitize_file_name () { echo "$@" | tr -d ''; }
| fi
| 
| # Can we create directories with trailing whitespace in their names?
| ac_cv_dir_trailing_space='yes'
| if test "$ac_cv_dir_trailing_space" = yes; then
|   func_sanitize_dir_name () { echo "$@"; }
| else
|   func_sanitize_dir_name () { echo "$@" | sed 's/  *$//'; }
| fi
| 
| # AUTOM4TE might be set in the environment.  Override it here so that
| # direct aclocal invocations also use it.
| AUTOM4TE=autom4te
| export AUTOM4TE

##  ##
## Tested programs. ##
##  ##

../../tests/local.at:25: /home/bruno/autoconf-2.72d/build-64/tests/autom4te --version
autom4te (GNU Autoconf) 2.72d
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
, 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Akim Demaille.

../../tests/local.at:25: /home/bruno/autoconf-2.72d/build-64/tests/autoconf --version
autoconf (GNU Autoconf) 2.72d
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
, 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

../../tests/local.at:25: /home/bruno/autoconf-2.72d/build-64/tests/autoheader --version
autoheader (GNU Autoconf) 2.72d
Copyright (C) 2023 Free Software Foundation, Inc.

Re: two recent NEWS entries

[Bruno Haible]

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

[Bruno Haible]

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-2038 support respectively.
As with AC_SYS_YEAR2038, application and library builders should
configure consistently.

What does the "except that they require ..." mean?

Does it mean that the configure run aborts when the requirement cannot
me met?

Or does it mean that AC_SYS_LARGEFILE_REQUIRED requires large-file
support without year2038 support, and AC_SYS_YEAR2038_REQUIRED requires
year2038 support without large-file support?

Or what else?

Can the text be clarified, please?

2) I think this paragraph is a bit misleading:

  *** AC_PROG_MKDIR_P now falls back on plain 'mkdir -p'.

When AC_PROG_MKDIR_P cannot find a mkdir implementation that is
known to lack race condition bugs, it now falls back on 'mkdir -p'
instead of falling back on a relative path to install-sh, as the
relative paths now seem to be a more important problem than the
problems of ancient mkdir implementations with race condition bugs.
See .  The only ancient
mkdir still in common use is Solaris 10 /usr/bin/mkdir, and for that
platform AC_PROG_MKDIR_P falls back on /opt/sfw/bin/mkdir which
should work.

because it sounds like on Solaris 10 there is no problem. But actually
on the 3 Solaris 10 machines I have access to (including gcc210.fsffrance.org),
there is no /opt/sfw/bin/mkdir. There is only /usr/bin/mkdir. So, on Solaris 10,
parallel builds will be unreliable (i.e. prone to failures), and the advice
should be to avoid the option '-j' of GNU make on this platform.

Bruno

[sr #110324] autoupdate does some nonsensical changes

[Bruno Haible]

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

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Bruno Haible]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Code snippets passed to AC_RUN_IFELSE, AC_LANG_IFELSE, and more generally
AC_LANG_CONFTEST, undergo the expansions inside unquoted here documents. This
comes from


cat > conftest.$ac_ext <<_ACEOF
AC_LANG_DEFINES_PROVIDED[]$1
_ACEOF


There is already user code that relies on this (in Gnulib, for example:
btowc.m4, fchownat.m4, gettext.m4, gnulib-common.m4, iswdigit.m4,
iswxdigit.m4, mbrlen.m4, mbrtoc32.m4, mbrtowc.m4, mbsnrtowcs.m4, mbsrtowcs.m4,
socklen.m4, stdint.m4, strfmon_l.m4, warn-on-use.m4, wcrtomb.m4,
wcsnrtombs.m4, wcsrtombs.m4, wctob.m4). Therefore it's unlikely that this can
ever be changed.

But people who write invocations AC_RUN_IFELSE, AC_LANG_IFELSE, etc. need to
be aware of it, otherwise it's easy to introduce bugs. See the first patch
from https://lists.gnu.org/archive/html/bug-gnulib/2021-07/msg00025.html

The Autoconf documentation should mention that in such code snippets, $
expansion references environment variables, and $ and \ meant as literal
values need to be backslash-escaped.





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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 GNU m4 version.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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" <<_ACAWK &&
gawk: ./conf0h1pqt/subs.awk:1691: ^ syntax error
config.status: error: could not create Makefile


Find attached a tarball that contains
- the configure script,
- the broken config.status,
- the correct config.status (generated with CONFIG_SHELL=/usr/bin/bash).

(file #51026)
___

Additional Item Attachment:

File name: sh-bug.tar.gz  Size:363 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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 __xpg6
makes it impossible to build reliably working libraries. So, I withdraw this
suggestion.

> The test for C99 compliance was made pickier in Autoconf 2.70, and
-D_STDC_C99, which it does use, is no longer enough for Sun's compiler to pass
the test.

I have now documented the use of -D_STDC_C99 in
https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration;
nevertheless it was good that Autoconf 2.69 added -D_STDC_C99 automatically.
Support for part of C99 is better than support for none of C99. Therefore a
less picky test is better than a pickier one.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Solaris

___

Details:

This is a regression in autoconf 2.71, compared to autoconf 2.69.

Find attached two tarballs, hello-c-2.69.tar.gz (generated with autoconf 2.69)
and hello-c-2.71.tar.gz (generated with autoconf 2.71). They contain the same
source code, except for the version number in configure.ac. In particular,
they contain
  - in configure.ac, an AC_PROG_CC_C99 invocation,
  - in hello.c: code that requires C99.

The commands to regenerate everything in these tarballs is:

aclocal -I m4
autoconf
autoheader
automake -a -c
rm -rf autom4te.cache


On Solaris 10, I'm using CC="cc -O". This compiler is not C99 compliant, but
it accepts the option '-xc99' which makes it C99 compliant.

Both packages ought to exhibit the same behaviour, but they don't:

* The hello-c-2.69 package compiles fine.
  ./configure prints:

checking whether we are using the GNU C compiler... no
checking whether cc -O accepts -g... yes
checking for cc -O option to accept ISO C89... none needed
checking whether cc -O understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of cc -O... none
checking for cc -O option to accept ISO C99... -D_STDC_C99=

The option '-D_STDC_C99=' is probably not entirely equivalent to '-xc99', but
it is good enough: The compilation command

cc -O -D_STDC_C99= -DHAVE_CONFIG_H -I. -I..  -g -c -o hello.o ../hello.c

succeeds.

* The hello-c-2.71 package does not build.
  ./configure prints:

checking whether the compiler supports GNU C... no
checking whether cc -O accepts -g... yes
checking for cc -O option to enable C11 features... unsupported
checking for cc -O option to enable C99 features... unsupported
checking for cc -O option to enable C89 features... none needed

Then the compilation command fails:

cc -O -DHAVE_CONFIG_H -I. -I..  -g -c -o hello.o ../hello.c
"/usr/include/sys/feature_tests.h", line 341: #error: "Compiler or options
invalid; UNIX 03 and POSIX.1-2001 applications   require the use of c99"
cc: acomp failed for ../hello.c
*** Error code 2


When I set CC="cc -O -xc99", then ./configure prints

checking whether the compiler supports GNU C... no
checking whether cc -O -xc99 accepts -g... yes
checking for cc -O -xc99 option to enable C11 features... unsupported
checking for cc -O -xc99 option to enable C99 features... none needed

and the compilation command succeeds:

cc -O -xc99 -DHAVE_CONFIG_H -I. -I.. -g -c -o hello.o ../hello.c


So, that is a workaround. But the point of the AC_PROG_CC_C99 macro is that
the autoconfiguration finds out about the '-xc99' by itself, isn't it?




___

File Attachments:


---
Date: Sat 27 Feb 2021 09:05:03 PM CET  Name: hello-c-2.69.tar.gz  Size: 75KiB 
 By: haible


---
Date: Sat 27 Feb 2021 09:05:03 PM CET  Name: hello-c-2.71.tar.gz  Size: 75KiB 
 By: haible



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110435] autoreconf does not recognize AM_ICONV

[Bruno Haible]

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 should use the gnulib module 'iconv'. This module includes the
config.rpath file.

autoreconf deals with gettext for convenience. It does not know about gnulib
modules.

> projects which needs to use AM_ICONV started providing their own
"autogen.sh" script which copies required file config.rpath to current
directory and then run autoreconf.

This is not future-proof: if new files (.m4 files or else) are needed as new
dependencies of iconv.m4, this method will not know about it.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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 sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Mac OS

___

Details:

This is a regression in autoconf 2.70, compared to version 2.69:

Take a tarball with C source code that makes use of C99 features. For
example:

./gnulib-tool --create-testdir --dir=../testdir5 --single-configure dfa

(with current gnulib).

Build it on Mac OS X 10.5, with CC="gcc -m64".

With autoconf 2.69, the config.status file contains

S["CC"]="gcc -m64 -std=gnu99"

and the compilation goes through.

With autoconf 2.70, the config.status file contains

S["CC"]="gcc -m64"

and the compilation fails with errors such as "error: 'for' loop initial
declaration used outside C99 mode".






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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 following values right?

solaris11omnios-x86-32-gcc  CC="gcc -m32 -O2"  CXX="g++ -m32 -O2" 
CONFIG_SHELL=/bin/bash

solaris11omnios-x86-64-gcc  CC="gcc -m64 -O2"  CXX="g++ -m64 -O2" 
CONFIG_SHELL=/bin/bash

Or, if you want, I can let you edit this table.

> This Google reference (which is likely based on Google Search data) is 
> very annoying to me and it seems irrelevant.  There is no need to 
> diminish a viable free operating system.

I didn't purposely diminish OmniOS. But Zack asked for our thoughts on
how to deal with a bug. As usual, "add workaround to the code" and
"add workaround to the documentation" are viable alternatives. In my
opinion, the size of the user base does play a role. If every other
circumstances were equal, I would spend more time on a workaround for
FreeBSD than on a workaround for OmniOS. And I would recommend the same
thing to Zack.

How to estimate the size of the user base of an OS? Like you, I dislike
Google. But their trends site is a way to do such estimations, and I know
of no other or better way. (For packages, but not for OSes, there is also
the Debian popularity contest.)

> In a similar spirit, I should point out that Illumos is doing better 
> than CLISP according to trends.google.com since the limited 
> popularlity is stable and not dwindling. ;-)

Indeed, CLISP failed to achieve world domination. JavaScript did, instead.
I failed. ;-)

Bruno

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

[Bruno Haible]

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 environment variable
CONFIG_SHELL=/path/to/bash,

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.

It's not worth the complexity in Autoconf for a short-lived bug in a
small-community system, when a workaround is so easy to put in place.

References:
[1] https://en.wikipedia.org/wiki/Comparison_of_OpenSolaris_distributions
[2] trends.google.com


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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 freestanding implementations, so test against a dummy declaration.
# Include always-available headers on the off chance that they somehow
# elicit warnings.
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h.  */
#include 
#include 
#include 
#include 
extern void ac_decl (int, char *);
int
main (void)
{
#ifdef __cplusplus
  (void) ac_decl ((int) 0, (char *) 0);
  (void) ac_decl;
#else
  (void) ac_decl;
#endif

  ;
  return 0;
}
_ACEOF
if ac_fn_c_try_compile "$LINENO"
then :
  if test -s conftest.err
then :
  { { printf "%s\n" "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
printf "%s\n" "$as_me: error: in \`$ac_pwd':" >&2;}
as_fn_error $? "cannot detect from compiler exit status or warnings
See \`config.log' for more details" "$LINENO" 5; }


The problem here is the semicolon before 'return 0', which comes from the
AC_LANG_PROGRAM macro. It triggers a clang warning. And since all or most test
programs used by Autoconf are pieced together using AC_LANG_PROGRAM, the
presence of warnings cannot be used to detect anything about the test program.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

This worked with autoconf 2.69 generated configure files; with autoconf 2.70
generated configure files the configuration aborts like this:


checking how clang -Wextra-semi-stmt reports undeclared, standard C
functions... configure: error: in `/testdir1/build-64':
configure: error: cannot detect from compiler exit status or warnings
See `config.log' for more details


This can be reproduced:
a) on a Unix system, with CC="clang -Wall -Wextra-semi-stmt",
b) on a Windows system, with CC="$HOME/compile clang-cl -Wall".

(Apparently 'clang-cl' enables some more warnings on Windows, than 'clang' on
Unix. Probably for MSVC compatibility.)





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110294] AC_LANG_PUSH/AC_LANG_POP malfunction inside AC_DEFUN

[Bruno Haible]

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's going on.
Are there debugging tools or debugging tips available for this situation (that
could be documented in the manual)? I also tried head-scratching, and for me
it was enough to resolve the issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110294] AC_LANG_PUSH/AC_LANG_POP malfunction inside AC_DEFUN

[Bruno Haible]

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],
  [
   AC_COMPILE_IFELSE(
 [AC_LANG_PROGRAM(
[[#include ]],
[[]])
 ],
 [gl_cv_cxxheader_cuchar=yes],
 [gl_cv_cxxheader_cuchar=no])
  ])
AC_LANG_POP([C++])


invokes AC_COMPILE_IFELSE with the current language set to C++. 
AC_COMPILE_IFELSE calls AC_LANG_COMPILER_REQUIRE, which AC_REQUIREs
AC_LANG_COMPILER(C++), which AC_REQUIREs AC_PROG_CXX.  Because of your earlier
"kind of an optional AC_PROG_CXX" code, this causes the AC_LANG machinery to
get confused about what the correct setting for $ac_compile is, for checks in
between the top of the AC_DEFUN and the AC_LANG_PUSH.

We can't support your code as-is in Autoconf 2.70.  However, I can offer you a
simple workaround.  Move all of the "optional AC_PROG_CXX" code into a new
AC_DEFUN.  Make the last line of that AC_DEFUN be


m4_provide([AC_PROG_CXX])


(right after the "Determine a good default for CXXFLAGS" if-block).

In my testing, those modifications make your sample configure script work
correctly.  They should be harmless with 2.69.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

The section about CFLAGS in section "Preset Output Variables"
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Preset-Output-Variables.html
was written in 2006, see
https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=63b0709b9482f1a282d584239d3bcb016633d7cf
.

This text considers the habits of Makefile authors and of Automake, when to
use CC with CFLAGS and CPPFLAGS (namely for preprocessing and compiling to
object files) vs. CC with CFLAGS and LDFLAGS (namely for linking).

However, another use of CC is in config.guess, when the user has not provided
a --host option. Here, at least nowadays, CC is used without CFLAGS, CPPFLAGS,
nor LDFLAGS.

This variable is used on GNU/Linux, Solaris, HP-UX systems to determine
whether the build produces 32-bit or 64-bit binaries, and sets the host_cpu
portion of the config.guess result accordingly. See
https://lists.gnu.org/archive/html/config-patches/2018-12/msg00012.html .

When users put -m32 or -m64 options into variables other than CC, this
detection does not work and causes problems thereafter. See
https://lists.gnu.org/archive/html/bug-gnulib/2020-12/msg00012.html for an
example.

Find attached a patch to the Autoconf documentation, to make it clear that
-m32 or -m64 options need to go into CC.




___

File Attachments:


---
Date: Tue 01 Dec 2020 11:00:50 PM CET  Name:
0001-Document-better-where-to-put-m32-or-m64-compiler-opt.patch  Size: 2KiB  
By: haible



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Priority: 5 - Normal
Severity: 4 - Important
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

In GNU gettext, autoconf 2.69d gave a number of "obsolete" warnings. I fixed
those that I could fix. But some remain:


configure.ac:95: warning: The macro `AC_LANG_SAVE' is obsolete.
configure.ac:95: You should run autoupdate.
./lib/autoconf/lang.m4:126: AC_LANG_SAVE is expanded from...
../m4/libtool.m4:8072: _LT_LANG_RC_CONFIG is expanded from...
../m4/libtool.m4:841: _LT_LANG is expanded from...
../m4/libtool.m4:823: LT_LANG is expanded from...
configure.ac:95: the top level
configure.ac:95: warning: The macro `AC_LANG_RESTORE' is obsolete.
configure.ac:95: You should run autoupdate.
./lib/autoconf/lang.m4:135: AC_LANG_RESTORE is expanded from...
../m4/libtool.m4:8072: _LT_LANG_RC_CONFIG is expanded from...
../m4/libtool.m4:841: _LT_LANG is expanded from...
../m4/libtool.m4:823: LT_LANG is expanded from...
configure.ac:95: the top level


There are two problems here:
1) [Major] Libtool is not actively maintained (no release in 5 years, and no
commit in 1.5 years). Therefore libtool.m4 is likely to produce the same
warnings for the next 2 years or so. And there are MANY packages that use
libtool.m4, and most of them don't really want to apply local modifications to
libtool.m4.
2) [Normal] The Autoconf documentation describes what AC_LANG_SAVE and
AC_LANG_RESTORE should be replaced with. I tried it, and got an error because
Autoconf does not define a language named 'rc'.

Problem 2 may be surmountable with a couple of hours of effort, but problem 1
is not.

For this reason, 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.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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,
the configure script will make use of it in AC_RUN_IFELSE invocations;
otherwise, cross-compilation
mode is enabled."

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110305] Replace autom4te output file atomically

[Bruno Haible]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

In the attached example configure.ac, there is a line

dnl AC_OUTPUT([Makefile])

and autoupdate 2.69c transforms it to

dnl AC_CONFIG_FILES([Makefile])
AC_OUTPUT


Since there is already an AC_OUTPUT invocation in the configure.ac file, now
there are two AC_OUTPUT invocations!

IMO, either autoupdate should leave comment lines untouched, or should add a
'dnl ' prefix to all continuation lines of the expansion.



___

File Attachments:


---
Date: Mon 05 Oct 2020 12:57:35 AM CEST  Name: configure.ac  Size: 32KiB   By:
haible


---
Date: Mon 05 Oct 2020 12:57:35 AM CEST  Name: configure.ac.diff  Size: 1KiB  
By: haible



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Microsoft Windows

___

Details:

On 64-bit native Windows, pid_t has to be a 64-bit type, as explained in
https://lists.gnu.org/archive/html/bug-gnulib/2020-08/msg00209.html .

With mingw, there is no problem, as mingw defines pid_t correctly.

But on MSVC (and MSVC/clang), the type pid_t is not defined, neither by the
standard header files nor by the compiler. The AC_TYPE_PID_T therefore kicks
in and defines it. But it defines it incorrectly, namely to 'int', where
instead 'long long' or '__int64' is the correct definition. For compatibility
with MSVC versions < 14 (older than 2015), it is best to use '__int64', as
support for 'long long' was only added in MSVC 14 (Visual Studio 2015).

Patch is attached.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110294] AC_LANG_PUSH/AC_LANG_POP malfunction inside AC_DEFUN

[Bruno Haible]

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-current-language disagree, and I happened to hit one of them?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110294] AC_LANG_PUSH/AC_LANG_POP malfunction inside AC_DEFUN

[Bruno Haible]

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
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

With Autoconf 2.69, a wrong configure file is generated when the configure.ac
file (attached) contains
  - an AC_DEFUN,
  - an AC_LANG_PUSH([C++]) / AC_LANG_POP([C++]) pair inside the AC_DEFUN,
  - no AC_LANG_CXX invocation (because my package has optional C++ support;
invoking AC_LANG_CXX would make configure abort if no C++ compiler is found,
which is not what I want).

How to reproduce:
1. In an empty directory, save the attached configure.ac file.
2. aclocal
3. autoconf
4. touch install-sh
5. configure

The output contains:

checking for library needed for log()... 
checking whether the C++ compiler has ... no
checking for library needed for pow()... -lm


So, autoconfiguration has correctly determined that use of pow() needs linking
with -lm. But it has incorrectly determined that use of log() does not need
linking with -lm. Why? The config.log shows it:

configure:4398: checking for library needed for log()
configure:4416: g++ -o conftest -g -O2   conftest.cpp  >&5
configure:4416: $? = 0
...
configure:4480: checking for library needed for pow()
configure:4498: gcc -o conftest -g -O2   conftest.c  >&5
/tmp/ccYm3cJH.o: In function `main':
/tmp/1/conftest.c:19: undefined reference to `log'
collect2: error: ld returned 1 exit status
configure:4498: $? = 1

You can see that it has executed the log() test with the C++ compiler! And
since libstdc++ is linked with libm (use 'ldd' to confirm this), the "g++ -o
conftest -g -O2   conftest.cpp" command succeeded.

The configure script uses a variable 'ac_compile'. See where it is being set:

$ grep -n '\(ac_compile=\|\)' configure
1882:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
2498:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3281:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3287:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3339:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3695:ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3719:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3870:ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3991:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
4012:ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
4263:ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
4406: #include 
4430:ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
4464:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
4488: #include 

You can clearly see that the last assignment to ac_compile before the first
 test is in line 4263 and that it prepares for use of the C++
compiler, not of the C compiler.

The bizarre thing is that when adding an invocation of AC_PROG_CXX (at one of
the two places indicated by a comment "This fixes it!") makes the bug
disappear. Then we see

$ grep -n '\(ac_compile=\|\)' configure
1882:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
2498:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3281:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3287:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3339:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3695:ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3719:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3870:ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
3991:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
4008:ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
4259:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
4406: #include 
4430:ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
4464:ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
4488: #include 

Here the last assignment to ac_compile before the first  test
activates the C compiler. This is good. But as I said above, I do not want to
use AC_PROG_CXX.



___

File Attachments:


---
Date: Tue 18 Aug 2020 06:38:28 PM CEST  Name: configure.ac  Size: 3KiB   By:
haible



___

Reply to this item at:

  

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

[Bruno Haible]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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/
# See https://www.openbsd.org/faq/faq15.html#PkgMgmt
Edit ~/.profile to define PKG_PATH:
PKG_PATH=https://ftp.hostserver.de/pub/OpenBSD/6.7/packages/`uname -m`/
export PKG_PATH
Logout.

# pkg_add bzip2
# pkg_add gtar
# pkg_add bash
# pkg_add gmake
# pkg_add vim, pick no_x11 variant
# pkg_add emacs, pick no_x11 variant


> GNU Make sets MAKEFLAGS=w in the environment, and presumably this confuses
OpenBSD Make.

Indeed: The GNU make behaviour is explained in the thread starting at
https://lists.gnu.org/archive/html/help-make/2016-03/msg9.html . Whereas
the OpenBSD make's interpretation of MAKEFLAGS is documented in
https://man.openbsd.org/make .

So, really, inside of GNU make invocations on OpenBSD, one should avoid
invoking 'make'.

> One possibility is that you need to be consistent about which 'make' you're
using, e.g., './configure MAKE=gmake'.

No, this does not help because tests/autotest.at lines 1938 and 1999 invokes
precisely 'make', even it the environment variable MAKE is set. How about
writing ${MAKE-make} instead?


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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 in the log file is

make: don't know how to make w


To me, it smells like 'gmake' has set some environment variables, and the test
is invoking 'make', and 'make' interprets this environment variable in a
strange way.

(file #49510, file #49511)
___

Additional Item Attachment:

File name: openbsd67-logs.tar.xz  Size:157 KB


File name: openbsd67-vpath-logs.tar.xzSize:159 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: *BSD

___

Details:

On OpenBSD 6.5, when running the test suite of autoconf-2.69 and -2.69b, two
tests fail in 2.69b that did not exist in 2.69:

 221: autotest.at:1893   C unit tests
 222: autotest.at:1948   C unit tests (EXEEXT)


Find attached the test logs.



___

File Attachments:


---
Date: Fri 17 Jul 2020 11:00:47 PM CEST  Name: openbsd-logs.tar.xz  Size:
192KiB   By: haible



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Solaris

___

Details:

On Solaris 11 OpenIndiana, when running the test suite of autoconf-2.69 and
-2.69b, one test fails in 2.69b that did not exist in 2.69:

 221: autotest.at:1893   C unit tests


Find attached the test logs.



___

File Attachments:


---
Date: Fri 17 Jul 2020 10:53:04 PM CEST  Name: openindiana-logs.tar.xz  Size:
276KiB   By: haible



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

Hi Paul,

> Thanks for the bug report. I reverted the patch in question, and then updated
> the manual to mention cross-compiling for mingw as an example.

Thanks.

I still feel that this documentation can be improved:

  - It currently says that --host "enables cross-compilation", which is
half right and half wrong (it's right regarding host-type-TOOL programs,
and it's wrong regarding AC_RUN_IFELSE).

  - It says "For historical reasons, whenever you specify ‘--host’, be sure to
specify ‘--build’ too". This sentence is obsolete. I'm building 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 2001
From: Bruno Haible 
Date: Wed, 15 Jul 2020 22:34:24 +0200
Subject: [PATCH] doc: More clarifications regarding --host and --build.

* doc/autoconf.texi (Specifying Target Triplets): Describe the effects of --host
in more detail. Don't recommend to specify --build when specifying --host. Add
another example regarding MinGW.
---
 doc/autoconf.texi | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 64129db..d514394 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -21929,21 +21929,36 @@ cross-compilation mode.
 
 @item --host=@var{host-type}
 the type of system on which the package runs.  By default it is the
-same as the build machine.  Specifying a @var{host-type} that differs
+same as the build machine.  The tools that get used to build and
+manipulate binaries will, by default, all be prefixed with
+@code{@var{host-type}-}, such as @code{@var{host-type}-gcc},
+@code{@var{host-type}-g++}, @code{@var{host-type}-ar}, and
+@code{@var{host-type}-nm}.  If the binaries produced by these tools can
+be executed by the build system, the configure script will make use of
+it in @code{AC_RUN_IFELSE} invocations; otherwise, cross-compilation
+mode is enabled.  Specifying a @var{host-type} that differs
 from @var{build-type}, when @var{build-type} was also explicitly
-specified, enables cross-compilation mode.
+specified, equally enables cross-compilation mode.
 
 @item --target=@var{target-type}
 the type of system for which any compiler tools in the package
 produce code (rarely needed).  By default, it is the same as host.
 @end table
 
-If you mean to override the result of @command{config.guess}, use
-@option{--build}, not @option{--host}, since the latter enables
-cross-compilation.  For historical reasons,
-whenever you specify @option{--host},
-be sure to specify @option{--build} too; this glitch should be fixed in the
-future.  So, to enter cross-compilation mode, use a command like this
+If you mean to override the result of @command{config.guess} but
+still produce binaries for the build machine, use @option{--build},
+not @option{--host}.
+
+So, for example, to produce binaries for 64-bit MinGW, use a command
+like this:
+
+@example
+./configure --host=x86_64-w64-mingw64
+@end example
+
+If your system has the ability to execute MinGW binaries but you don't
+want to make use of this feature and instead prefer cross-compilation
+guesses, use a command like this:
 
 @example
 ./configure --build=x86_64-pc-linux-gnu --host=x86_64-w64-mingw64
-- 
2.7.4

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

[Bruno Haible]

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 GNU/Linux distributions set
Wine to automatically handle Windows binaries." (and Wine is buggy). For these
cases, the user can turn off the execution of the test programs either by not
installing/activating Wine, or by passing the option
--build=x86_64-unknown-linux-gnu in addition to --host=x86_64-w64-mingw32.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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: None
Priority: 5 - Normal
Severity: 4 - Important
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

This is a regression, compared to 2.69.

In situations where a platform is used as a development environment - with
program execution capability - for a different platform, AC_RUN_IFELSE now
does not execute the test program although it could; it falls back to the
cross-compilation guess instead.

This affects in particular
1) native Windows (mingw or MSVC) compilation in a Cygwin environment,
2) cross-compilation to Linux with a different architecture, on Linux.

Details about the environments:
1) See
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=INSTALL.windows
2) For example, cross-compilation to Linux/m68k from Linux/x86_64 (Ubuntu
16.04). See
https://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob;f=porting-tools/emulation/qemu-m68k.txt
. The configure command I use is:

configure --prefix=/inst-m68k --host=m68k-linux CPPFLAGS="-I/inst-m68k/include
-Wall" LDFLAGS="-L/inst-m68k/lib"


The behaviour of AC_RUN_IFELSE is specified in the Autoconf documentation:
"If cross-compilation mode is enabled (this is the case if either the compiler
being used does not produce executables that run on the system where
@command{configure} is being run, or if the options @code{--build} and
@code{--host} were both specified and their values are different), then the
test program is not run."
This documentation has not changed since 2.69, and it makes perfect sense: it
generally allows to determine actual program behaviour, and it has a way to
disable it (in cases where that's needed).

In my case, the generated executables DO run in the environment, and I did NOT
specify a --build option. Therefore AC_RUN_IFELSE should execute the test
program.

Instead, what I see when configuring a gnulib testdir, generated with
+verbose+
  ./gnulib-tool --create-testdir --dir=../testdir-posixb --with-c++-tests
--single-configure `./posix-modules`
-verbose-
through
+verbose+
  ./configure --prefix=/inst-m68k --host=m68k-linux
CPPFLAGS="-I/inst-m68k/include -Wall" LDFLAGS="-L/inst-m68k/lib" -C 2>&1 | tee
log1
-verbose-
for Linux/m68k is that all AC_RUN_IFELSE invocation used the cross-compilation
branch, not the test program:

+verbose+
$ diff testdir-posix/build-m68k/config.cache
testdir-posixb/build-m68k/config.cache |head
16a17
> ac_cv_c_decl_report=${ac_cv_c_decl_report=error}
65c66
< ac_cv_func_chown_works=${ac_cv_func_chown_works=yes}
---
> ac_cv_func_chown_works=${ac_cv_func_chown_works='guessing yes'}
107c108
< ac_cv_func_getgroups_works=${ac_cv_func_getgroups_works=yes}
---
> ac_cv_func_getgroups_works=${ac_cv_func_getgroups_works='guessing yes'}
...
-verbose-
See attached file config.cache.diff.




___

File Attachments:


---
Date: Wed 15 Jul 2020 09:58:09 AM CEST  Name: config.cache.diff  Size: 31KiB  
By: haible



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Priority: 5 - Normal
Severity: 4 - Important
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

As explained in
https://lists.gnu.org/archive/html/bug-autoconf/2018-12/msg1.html, the
AC_PROG_YACC macro, which did support Yacc well in 2.69, now is buggy.

The change
https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=42761668c0300afa7f8bf5ba736458a818cd5d15
should better be reverted and instead a new macro AC_PROG_BISON should be
added, for proper Bison support.

Akim Demaille, the original author of said change, approved the plan in
https://lists.gnu.org/archive/html/bug-autoconf/2018-12/msg2.html .




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Add documentation to AC_EGREP_CPP and AC_EGREP_HEADER, warning about the
problem described in
https://lists.gnu.org/archive/html/bug-autoconf/2017-02/msg1.html
Namely:

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.





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Bruno Haible]

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 -
is undesirable and should be obsoleted by the next Autoconf version.

For this reason, I would find it better to find workarounds that
are more directed to the solution that we'll want to have in the
next Autoconf version. To that effect:

  1. Think about what the solution in the next Autoconf version
 should look like. (A modification to AC_LANG_PROGRAM? Or
 a new macro, in order to keep backward compatibility for
 existing macros?)

  2. Put into gnulib's gnulib-common.m4 workarounds that make it
 possible to write autoconf macros for Autoconf 2.70, as if
 Autoconf 2.70 was already released.

  3. Then only document things. If we decide to make incompatible
 changes to AC_LANG_PROGRAM and friends, do NOT document the
 current (broken) behaviour. By documenting a broken behaviour,
 you would make things worse.

Bruno

Yacc support vs. Bison support

[Bruno Haible]

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, that use one or more of the many (useful) Bison extensions.

What are the problems with the Yacc support?

  None I know of.

What are the problems with the Bison support?

  (A) When configure runs on a machine that has a BSD yacc installed, but no
  bison installed, the variable YACC gets set to 'yacc', and 'make'
  fails because 'yacc' of course does not support the Bison extensions.

  (B) The newly introduced warnings in Bison 3.3+

https://git.savannah.gnu.org/gitweb/?p=bison.git;a=commitdiff;h=d92ed9d9f72bfe98dfee5d13800aef95b87c82c6
  will warn about intended uses of Bison extensions.

  (C) The Automake documentation
  https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
  advertises Yacc support, but no Bison support.

Problem (A) has been widely recognized; it is the reason for the
separate macros bison.m4 and INTLBISON in intl.m4 (both in gnulib).

Now comes the patch from 2013-03-19
https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=42761668c0300afa7f8bf5ba736458a818cd5d15
presented in
https://lists.gnu.org/archive/html/autoconf-patches/2013-03/msg0.html

What it does is to remove (B) from the list of problems in the Bison support
and add it to the problems of Yacc support. Namely:

Now the problems of Yacc support are:

  (B') The newly introduced warnings in Bison 3.3+ - which would be
   useful for this case - cannot be activated.
   (The advice given in autoconf/NEWS, "Add -Wyacc to your YFLAGS to
   enable them." cannot be followed because the BSD yacc does not
   understand the -Wyacc option.)

Now the problems of Bison support are:

  (A) as above
  (C) as above

This is not a good situation, IMO. I would suggest to come to good support
for Bison sources, while at the same time not regress on the support for
Yacc sources, as follows:

  1) Revert the patch from 2013-03-19.

  2) Introduce a macro AC_PROG_BISON (or AC_PROG_YACC_BISON if you prefer)
 that sets the YACC variable, with the following differences:

 - It takes an optional version argument that specifies the minimum
   Bison version needed.

 - If a non-Bison yacc or a Bison version smaller than that version is
   found, it sets the YACC variable to ':'. Rationale:

   dnl bison is only needed for the maintainer (who touches the *.y
   dnl sources). But in order to avoid separate Makefiles or
   dnl --enable-maintainer-mode, we put the rule in general Makefile.
   dnl Now, some people carelessly touch the files or have a broken
   dnl "make" program, hence the generated .y -> .c rule will sometimes
   dnl fire. To avoid an error, defines YACC to ":" if it is not
   dnl present or too old.

 - If a Bison in the expected version range is found, set YACC to
   'bison -o y.tab.c'.

  3) In Automake, mention the Bison support in the documentation. And
 change the error message

   Makefile.am: error: Yacc source seen but 'YACC' is undefined
   Makefile.am:   The usual way to define 'YACC' is to add 'AC_PROG_YACC'
   Makefile.am:   to 'configure.ac' and run 'autoconf' again.

 to

   Makefile.am: error: Yacc or Bison source seen but 'YACC' is undefined
   Makefile.am:   The usual way to define 'YACC' is to add 'AC_PROG_YACC' or
   Makefile.am:   'AC_PROG_BISON' to 'configure.ac' and run 'autoconf' 
again.


How does that sound? As far as I can see, this would solve the problems
(A), (B), (C) in the Bison support, while at the same time not regressing
behind 2.69 regarding the Yacc support.

Bruno

Re: AC_EGREP_CPP and AC_EGREP_HEADER users - beware of recent gcc

[Bruno Haible]

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 when it's supported ?

Yes, good idea!

Bruno

[GNU Autoconf 2.69] testsuite: 231 failed

[Bruno Haible]

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 \
  CXX=g++ -m32 -march=i586 \
  FC=gfortran -m32 -march=i586 \
  LDFLAGS=-m32 \
  CPPFLAGS=-Wall
$ make
$ make check

Details from tests/testsuite.log:

## -- ##
## Detailed failed tests. ##
## -- ##

# -*- compilation -*-
231. base.at:683: testing configure directories ...
./base.at:697: autoconf --force 
./base.at:697: /bin/sh -n configure
stderr:
./base.at:699: ./configure $configure_options --libdir=.
stderr:
configure: error: expected an absolute directory name for --libdir: .
stdout:
./base.at:700: grep 'expected an absolute directory name for --libdir: \.' 
stderr
stdout:
configure: error: expected an absolute directory name for --libdir: .
./base.at:704: ./configure $configure_options --prefix=/usr//
stdout:
configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
configure: creating ./config.status
config.status: creating foo
./base.at:705: cat foo
--- -   2012-04-25 10:23:03.009476526 +0200
+++ 
/home/bruno/data/build/autoconf-2.69/tests/testsuite.dir/at-groups/231/stdout   
2012-04-25 10:23:03.0 +0200
@@ -1,4 +1,4 @@
 prefix=/usr
 exec_prefix=${prefix}
-libdir=${exec_prefix}/lib
+libdir=${exec_prefix}/lib64
 

This is apparently due to the CONFIG_SITE environment variable that points
to /usr/share/site/x86_64-unknown-linux-gnu. See
http://lists.gnu.org/archive/html/bug-automake/2012-04/msg00093.html

Bruno

Re: [GNU Autoconf 2.69] testsuite: 231 failed

[Bruno Haible]

 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 \
   CPPFLAGS=-Wall
 $ make
 $ make check

PS: It can also be reproduced more simply in 64-bit mode (x86_64-pc-linux-gnu):

$ ./configure
$ make
$ make check

Bruno

Re: Getting AC_PROG_CC_C99

[Bruno Haible]

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 deprecate the other two macros?

There will soon be a new C standard, now codenamed C1X [1].

The description of AC_PROG_CC_STDC

 -- Macro: AC_PROG_CC_STDC
 If the C compiler cannot compile ISO Standard C (currently C99),
 ...

sounds like this macro will then be modified to enable C1X instead of C99.

But I expect that many packages will not need this. A package written to
use C99 will need AC_PROG_CC_C99, not AC_PROG_CC_STDC. 

The problems we have are:
  1) one cannot safely mix AC_PROG_CC_C99 and AC_PROG_CC_STDC [2],
  2) AC_PROG_CC_STDC will change its meaning in the future,
  3) AC_PROG_CC_C99 did not exist in Autoconf versions  2.60.
  4) AC_PROG_CC_STDC does not enforce C99 mode in Autoconf versions  2.60
 (says gnulib/modules/stdarg).

So, what people need to use now is
  m4_version_prereq([2.69], [AC_PROG_CC_C99], [AC_PROG_CC_STDC])

in the hope that Autoconf 2.69 will fix the first problem.

The sooner people can reliably use this idiom, the better.

Conclusion:
  - The fix of the first problem must occur in Autoconf before AC_PROG_CC_STDC
gets changed to require C1X,
  - It makes no sense to deprecate AC_PROG_CC_C99.

Bruno

[1] http://en.wikipedia.org/wiki/C1X
[2] http://lists.gnu.org/archive/html/bug-gnulib/2011-09/msg00367.html
-- 
In memoriam Kelsang Namtso 
http://en.wikipedia.org/wiki/Nangpa_La_shooting_incident

Re: system call trace tools

[Bruno Haible]

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 yourself)
- Solaris: truss
- HP-UX: tusc

Bruno
-- 
In memoriam Anna Göldi http://en.wikipedia.org/wiki/Anna_Göldi

avoid warning in AC_FUNC_STRERROR_R

[Bruno Haible]

Hi,

On OSF/1 with gcc and CPPFLAGS=-Wall, I'm seeing this warning in config.log:

  configure:22364: checking whether strerror_r returns char *
  configure:22416: gcc -std=gnu99 -o conftest -g -O2 -Wall  conftest.c  5
  conftest.c: In function 'main':
  conftest.c:174: warning: implicit declaration of function 'isalpha'
  configure:22416: $? = 0

Here's a proposed fix. All systems I know of have ctype.h.


2011-06-05  Bruno Haible  br...@clisp.org

AC_FUNC_STRERROR_R: Avoid gcc warning.
* lib/autoconf/functions.m4 (AC_FUNC_STRERROR_R): Include ctype.h
before using isalpha().

--- lib/autoconf/functions.m4.orig  Sun Jun  5 14:44:00 2011
+++ lib/autoconf/functions.m4   Sun Jun  5 14:43:20 2011
@@ -1649,6 +1649,7 @@
   # has a strerror_r that returns `int'.
   # This test should segfault on the DEC system.
   AC_RUN_IFELSE([AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT
+   #include ctype.h
extern char *strerror_r ();],
[[char buf[100];
  char x = *strerror_r (0, buf, sizeof buf);

-- 
In memoriam Eduard Lederer http://de.wikipedia.org/wiki/Eduard_Lederer

dashes in Makefile macro names

[Bruno Haible]

Hi,

Can you use $(FOO-BAR) in Makefile? It's not portable in POSIX [1]
  Applications shall select macro names from the set of characters
   consisting solely of periods, underscores, digits, and alphabetics
   from the portable character set
And the Autoconf manual too says that it's not portable [2].

But Paul Eggert found a number of such Makefile macro names in Emacs [3],
which have apparently not been hurting for years.

Prompted by this, I've tested the support for Makefile macro names with
dashes in
  - GNU make,
  - dmake 4.12,
  - smake 1.2.1,
  - the vendor 'make' in
- MacOS X,
- FreeBSD 6.4,
- OpenBSD 4.4,
- NetBSD 5.0,
- AIX 5.1,
- HP-UX 10.20,
- IRIX 6.5 (also pmake, smake),
- OSF/1 5.1,
- Solaris 2.6 (also dmake),
and found that all support it. The test was this Makefile:

== Makefile ===
FOO-BAR = yellow_dog
FOO_BAR = green_cat

all : $(FOO-BAR)

$(FOO-BAR) : greet_dog

$(FOO_BAR) : greet_cat

greet_dog:
echo hello my dog

greet_cat:
echo hello my cat


So I think it's time to update the Autoconf documentation by adding a
sentence. Here's a proposed patch.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
[2] 
http://www.gnu.org/software/autoconf/manual/html_node/Special-Chars-in-Names.html
[3] http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg01031.html


2011-01-28  Bruno Haible  br...@clisp.org

doc: Don't discourage dashes in Makefile macro names.
* doc/autoconf.texi (Special Chars in Names): Mention that dashes in
Makefile macro names are supported.

--- doc/autoconf.texi.orig  Fri Jan 28 12:34:38 2011
+++ doc/autoconf.texi   Fri Jan 28 12:26:49 2011
@@ -19183,10 +19183,12 @@
 @section Special Characters in Make Macro Names
 
 Posix limits macro names to nonempty strings containing only
-ASCII letters and digits, @samp{.}, and @samp{_}.  Many
-@command{make} implementations allow a wider variety of characters, but
-portable makefiles should avoid them.  It is portable to start a name
-with a special character, e.g., @samp{$(.FOO)}.
+ASCII letters and digits, @samp{.}, and @samp{_}.  Although Posix does
+not allow dashes @samp{-} in names, all known current @command{make}
+implementations support them.  Many @command{make} implementations allow
+a wider variety of characters, but portable makefiles should avoid them.
+It is portable to start a name with a special character, e.g.,
+@samp{$(.FOO)}.
 
 Some ancient @command{make} implementations don't support leading
 underscores in macro names.  An example is NEWS-OS 4.2R.

Re: [PATCH] stdbool: avoid rejecting clang

[Bruno Haible]

Paul Eggert wrote on 2010-08-24, in
http://lists.gnu.org/archive/html/bug-gnulib/2010-08/msg00170.html:
 the C standard
 says that s is a valid static initializer, but I suppose
 one could argue that there's an implicit conversion to bool that would
 clearly be invalid if one made it explicit and wrote (bool) s there.
 ...
 --- a/lib/autoconf/headers.m4
 +++ b/lib/autoconf/headers.m4
 @@ -628,7 +628,7 @@ AC_DEFUN([AC_HEADER_STDBOOL],
   char b[false == 0 ? 1 : -1];
   char c[__bool_true_false_are_defined == 1 ? 1 : -1];
   char d[(bool) 0.5 == true ? 1 : -1];
 - bool e = s;
 + /* See body of main program for 'e'.  */
   char f[(_Bool) 0.0 == false ? 1 : -1];
   char g[true];
   char h[sizeof (_Bool)];
 @@ -666,6 +647,7 @@ AC_DEFUN([AC_HEADER_STDBOOL],
   _Bool *pq = q;
]],
[[
 + bool e = s;
   *pq |= q;
   *pq |= ! q;
   /* Refer to every declared value, to avoid compiler optimizations.  */

This issue occurs again with Compaq C V6.5-303 on OSF/1 5.1.

source='test-stdbool.c' object='test-stdbool.o' libtool=no  DEPDIR=.deps 
depmode=tru64 /bin/ksh ./../build-aux/depcomp  cc -O -DHAVE_CONFIG_H -I.  
-DGNULIB_STRICT_CHECKING=1  -I. -I.  -I.. -I./..  -I../gllib -I./../gllib  
-ieee   -c -o test-stdbool.o test-stdbool.c
cc: Error: test-stdbool.c, line 65: In the initializer for e, the address 
cannot be converted to the destination type. (badstaticcvt)
bool e = s;
-^
*** Exit 1

After the test in m4/stdbool.m4 has been relaxed, the unit test needs to be
relaxed accordingly. Here's the patch that I will push:


2010-12-19  Bruno Haible  br...@clisp.org

stdbool: Relax test.
* tests/test-stdbool.c (e): Don't require that casts from a variable's
address to 'bool' work in static initializer, for compilers other than
GCC.

--- tests/test-stdbool.c.orig   Sun Dec 19 15:24:10 2010
+++ tests/test-stdbool.cSun Dec 19 15:23:08 2010
@@ -61,8 +61,13 @@
 char c[__bool_true_false_are_defined == 1 ? 1 : -1];
 #if HAVE_STDBOOL_H || defined __GNUC__ /* See above.  */
 char d[(bool) 0.5 == true ? 1 : -1];
-# ifdef ADDRESS_CHECK_OKAY
+# ifdef ADDRESS_CHECK_OKAY /* Avoid gcc warning.  */
+/* C99 may plausibly be interpreted as not requiring support for a cast from
+   a variable's address to bool in a static initializer.  So treat it like a
+   GCC extension.  */
+#  ifdef __GNUC__
 bool e = s;
+#  endif
 # endif
 char f[(_Bool) 0.0 == false ? 1 : -1];
 #endif
@@ -85,6 +90,13 @@
 int
 main ()
 {
+#if HAVE_STDBOOL_H || defined __GNUC__ /* See above.  */
+# ifdef ADDRESS_CHECK_OKAY /* Avoid gcc warning.  */
+  /* A cast from a variable's address to bool is valid in expressions.  */
+  bool e1 = s;
+# endif
+#endif
+
   /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
  reported by James Lemley on 2005-10-05; see
  http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html

bug with ${1+$@} in /bin/sh of Solaris 11 Express

[Bruno Haible]

Hi,

The Autoconf manual suggests to use ${1+$@} as a way to capture all
arguments of the currently running shell script.

Libtool uses this in its wrapper scripts.

But /bin/sh of Solaris 11 Express 2010-11 has a bug here: When the last
argument to be passed is an empty string, it is omitted.

The immediate effect is that unit tests of some programs may fail when
the package is configured with --enable-shared but succeed when it is
configured with --disable-shared.

Possible workarounds are:
  - Use /bin/bash instead of /bin/sh.
  - Test the number of arguments explicitly against 0, like this:
  case $# in
0) exec prog;;
*) exec prog $@;;
  esac

I've reported this as a bug in Solaris 11 Express. Since that release
is declared as not to be used for production or business use, I think
there's no need to modify the Autoconf manual or Libtool at this point;
just wait for the next Solaris 11 release, next year.

Bruno


== Contents that I posted in the Oracle bug tracker 
/bin/sh: expansion of ${1+$@} is incorrect

In /bin/sh shell scripts, the expansion of ${1+$@} is missing the last 
argument
if that argument is an empty string.

According to POSIX:2008
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html,
$@ and ${1+$@} should expand to the list of arguments, one by one, not
combined together, and not subject to word splitting. The second form is
commonly used as a workaround for platforms where the first form does not work,
see
http://www.gnu.org/software/autoconf/manual/html_node/Shell-Substitutions.html.

How to reproduce:
1) Save this as args.c
== args.c ==
#include stdio.h
#include stdlib.h
int main (int argc, char* argv[])
{
  int i;
  printf(argc = %d\n,argc);
  for (i = 0; i  argc; i++) printf(argv[%d] = %s\n,i,argv[i]);
  exit(0);
}
=
2) Compile it: gcc -o $HOME/bin/args args.c
3) Save this as args-caller.sh
 args-caller.sh =
#! /bin/sh
exec $HOME/bin/args ${1+$@} end
=
Make it executable: chmod a+x args-caller.sh
4) Run it with various arguments:

$ ./args-caller.sh ''
Actual output:
argc = 2
argv[0] = /home/bruno/bin/args
argv[1] = end
Expected output:
argc = 3
argv[0] = /home/bruno/bin/args
argv[1] = 
argv[2] = end

$ ./args-caller.sh foo '' ''
Actual output:
argc = 4
argv[0] = /home/bruno/bin/args
argv[1] = foo
argv[2] = 
argv[3] = end
Expected output:
argc = 5
argv[0] = /home/bruno/bin/args
argv[1] = foo
argv[2] = 
argv[3] = 
argv[4] = end

Re: noisy gnulib-tool on IRIX

[Bruno Haible]

Ralf Wildenhues wrote:
  (hmm, maybe autoconf should use that trick to reduce
  forking at m4sh startup).
 
   exec 32 2/dev/null; command; exec 23 3-
 
 has the advantage of not forking, the disadvantage of using another file
 descriptor (which we should probably disallow the user from passing in).

And it has the drawback of leaving the file descriptors in a broken state
when a signal is caught and a 'trap' handler is run. Namely, when a signal
is caught between the two execs, and the trap handler does an
  echo '*** caught signal' 12
the output is in fact redirected to /dev/null.

I conclude that it is bad practice to fiddle with file descriptors 0, 1, 2
in this way: It requires manual verification that no 'trap' handler is
installed that is subject to this problem, and will break the day someone
changes the effects of the trap handlers.

I'm therefore reverting to the common idiom of using a test in a subshell
  if (alias ...) /dev/null 2/dev/null; ...
I prefer maintainable reliable code, even if it costs one more 'fork'.

Bruno


2010-09-09  Bruno Haible  br...@clisp.org

gnulib-tool: Avoid stderr output on IRIX related to 'alias', 'unalias'.
* gnulib-tool: Don't fiddle with file descriptors 0, 1, 2. Instead, use
a reliable way to determine whether the 'alias' command works.

--- gnulib-tool.origThu Sep  9 11:37:32 2010
+++ gnulib-tool Thu Sep  9 11:36:54 2010
@@ -836,28 +836,24 @@
 # that the top-level statement containing the test starts after the 'alias'
 # command.
 if test -z $have_echo; then
-bsd_echo ()
+  bsd_echo ()
 {
 cat EOF
 $*
 EOF
 }
-exec 32
-exec 2/dev/null
-alias echo=bsd_echo
-exec 23
-exec 3-
+  if (alias echo=bsd_echo) 2/dev/null; then
+alias echo=bsd_echo 2/dev/null
+  fi
 fi
 if test -z $have_echo \
 echo '\t' | grep t  /dev/null; then
   have_echo=yes
 fi
 if test -z $have_echo; then
-  exec 32
-  exec 2/dev/null
-  unalias echo
-  exec 23
-  exec 3-
+  if (alias echo=bsd_echo) 2/dev/null; then
+unalias echo 2/dev/null
+  fi
 fi
 # For Solaris /bin/sh and OSF/1 /bin/sh: respawn using /bin/ksh.
 if test -z $have_echo \

Re: AC_FUNC_STRTOD

[Bruno Haible]

Hi,

Regarding the deprecation of AC_FUNC_* macros that are better provided by
gnulib:

Paolo Bonzini wrote in 
http://lists.gnu.org/archive/html/bug-autoconf/2010-06/msg00041.html:
  The affected macros are:
 - AC_FUNC_ERROR_AT_LINE
 
 If you're interested in this, you're likely using gnulib anyway nowadays.
 
  - AC_FUNC_STRTOD
  - AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
  - AC_FUNC_MKTIME
  - AC_FUNC_STAT, AC_FUNC_LSTAT
  - AC_FUNC_GETLOADAVG
  - AC_REPLACE_FNMATCH
 
 I don't think anyone knows even how to use these, i.e. where to get the 
 replacement (I think it was meant to be taken from libit...).  At this 
 point using gnulib is better.
 
  - AC_FUNC_MEMCMP
 
 This one should have been made obsolescent already, shouldn't it? 
 (Given the gnulib module is).
 
  - AC_FUNC_STRNLEN
 
 This maybe falls in the same group as AC_FUNC_MALLOC/AC_FUNC_REALLOC.
 
 - AC_FUNC_OBSTACK
 
 This one I would leave in too, obstacks are pretty self contained and I 
 think it is the most likely used in the wild.

OK, so the list of macros that should be marked obsolete is:

  - AC_FUNC_ERROR_AT_LINE
  - AC_FUNC_GETLOADAVG   (already marked obsolescent)
  - AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
  - AC_FUNC_MEMCMP   (already marked obsolescent)
  - AC_FUNC_MKTIME
  - AC_FUNC_STAT, AC_FUNC_LSTAT  (already marked obsolescent)
  - AC_FUNC_STRTOD
  - AC_REPLACE_FNMATCH   (already marked obsolescent)

Removing those that are already marked obsolescent, the following remain:

  - AC_FUNC_ERROR_AT_LINE
  - AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
  - AC_FUNC_MKTIME
  - AC_FUNC_STRTOD

Here is a proposed patch.


2010-08-28  Bruno Haible  br...@clisp.org

* doc/autoconf.texi (Particular Functions): Mark AC_FUNC_ERROR_AT_LINE,
AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK, AC_FUNC_MKTIME, AC_FUNC_STRTOD
as obsolete and refer to Gnulib.
* NEWS: Mention the change.

--- NEWS.orig   Sat Aug 28 11:46:36 2010
+++ NEWSSat Aug 28 11:42:54 2010
@@ -25,6 +25,14 @@
 ** Autotest testsuites should not contain long text lines any more, and be
portable even when very many test groups are used.
 
+** Newly obsolete macros
+   The following macros have been marked obsolete.  New programs should use
+   the corresponding Gnulib modules.  Gnulib not only detects the particular
+   portability problems but also provides complete workarounds.
+
+ AC_FUNC_ERROR_AT_LINE  AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
+ AC_FUNC_MKTIME  AC_FUNC_STRTOD
+
 
 * Major changes in Autoconf 2.67 (2010-07-21) [stable]
   Released by Eric Blake, based on git versions 2.66.*.
--- doc/autoconf.texi.orig  Sat Aug 28 11:46:36 2010
+++ doc/autoconf.texi   Sat Aug 28 11:34:51 2010
@@ -4876,6 +4876,9 @@
 
 The result of this macro is cached in the @code{ac_cv_lib_error_at_line}
 variable.
+
+The @code{AC_FUNC_ERROR_AT_LINE} macro is obsolescent.  New programs
+should use Gnulib's @code{error} module.  @xref{Gnulib}.
 @end defmac
 
 @defmac AC_FUNC_FNMATCH
@@ -5117,6 +5120,9 @@
 
 The result of this macro is cached in the
 @code{ac_cv_func_lstat_dereferences_slashed_symlink} variable.
+
+The @code{AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK} macro is obsolescent.
+New programs should use Gnulib's @code{lstat} module.  @xref{Gnulib}.
 @end defmac
 
 @defmac AC_FUNC_MALLOC
@@ -5206,6 +5212,9 @@
 
 The result of this macro is cached in the
 @code{ac_cv_func_working_mktime} variable.
+
+The @code{AC_FUNC_MKTIME} macro is obsolescent.  New programs should
+use Gnulib's @code{mktime} module.  @xref{Gnulib}.
 @end defmac
 
 @anchor{AC_FUNC_MMAP}
@@ -5385,6 +5394,9 @@
 
 This macro caches its result in the @code{ac_cv_func_strtod} variable
 and depends upon the result in the @code{ac_cv_func_pow} variable.
+
+The @code{AC_FUNC_STRTOD} macro is obsolescent.  New programs should
+use Gnulib's @code{strtod} module.  @xref{Gnulib}.
 @end defmac
 
 @defmac AC_FUNC_STRTOLD

Re: AC_FUNC_ALLOCA shouldn't define prototype

[Bruno Haible]

Eric Blake wrote:
 Rather than hard-code the check based on platform-specific defines, it
 would be more in the autoconf spirit to instead write a probe whether
 stdlib.h declares alloca(), and if so, define a witness macro.

Unfortunately, the code is also used in bison/data/yacc.c [1], that is, in the
skeleton that bison uses for a certain class of parsers. Therefore we have
to continue to find a code template that does not use information from a
configure script.

And the code is also in the Autoconf manual.

Thomas Klausner wrote:
 Do not fall through to the implicit prototype as it conflicts with
 stdlib.h.

More details:
- The declaration in the code snippet from Autoconf uses 'char *alloca();'.
- On FreeBSD, the declaration of alloca is only conditionally visible,
  namely if __BSD_VISIBLE. Its return type is 'void *', and the declaration
  is present since 1994.
- On OpenBSD, the declaration of alloca is only conditionally visible,
  namely if __BSD_VISIBLE since 2005; another condition was used before.
  Its return type is 'void *', and the declaration is present since 1995.
- On NetBSD, the declaration of alloca is only conditionally visible,
  namely if _NETBSD_SOURCE. Its return type is usually 'void *'.
- On all three systems, the double-inclusion guard of stdlib.h is
  _STDLIB_H_.

So, I don't understand how you see a conflict. The test code in
AC_FUNC_ALLOCA does not include stdlib.h, only stddef.h; how can that
clash? And after configure has run, the Autoconf manual recommends to
declare alloca as follows:

  #ifdef HAVE_ALLOCA_H
  # include alloca.h
  #elif defined __GNUC__
  # define alloca __builtin_alloca
  #elif defined _AIX
  # define alloca __alloca
  #elif defined _MSC_VER
  # include malloc.h
  # define alloca _alloca
  #else
  # include stddef.h
  # ifdef  __cplusplus
  extern C
  # endif
  void *alloca (size_t);
  #endif

This also cannot conflict with stdlib.h.

But seeing that no platform nowadays assumes a return type of 'char *' for
alloca, it would be possible to change the prototype anyway:


2010-08-05  Bruno Haible  br...@clisp.org

Modernize AC_FUNC_ALLOCA.
* lib/autoconf/functions.m4 (AC_FUNC_ALLOCA): Assume that alloca's
return type is 'void *', not 'char *'.

--- autoconf/lib/autoconf/functions.m4.orig Thu Aug  5 13:19:01 2010
+++ autoconf/lib/autoconf/functions.m4  Thu Aug  5 13:16:25 2010
@@ -388,7 +388,7 @@
  #pragma alloca
 #   else
 #ifndef alloca /* predefined by HP cc +Olibcalls */
-char *alloca ();
+void *alloca ();
 #endif
 #   endif
 #  endif

Bruno

[1] http://git.savannah.gnu.org/gitweb/?p=bison.git;a=blob;f=data/yacc.c;hb=HEAD

Re: characters allowed in --enable-*/--with-*

[Bruno Haible]

Hello Karl,

  Autoconf 2.66 added '+' to the set of allowed characters in --enable-*

 Why?

There were three reasons behind my proposal on bug-autoconf on 2010-03-13:

  1) For --enable/--disable: So that programs can use --enable-c++,
 which is easier for the user to remember than either --enable-cxx
 or --enable-cpp.

  2) For many libraries, --with options are used to specify the location
 of the library on the file system. This is done by GCC (see
 http://gcc.gnu.org/install/configure.html, which specifies e.g.
   --with-libart-prefix=PFX
   --disable-libarttest
 but also by packages which use the gnulib 'havelib' module.
 There are several libraries installed on a typical system that contain
 plus signs:
libg++
libFLAC++
libgpgme++
libncurses++
 Why should a user not be able to type --with-libg++-prefix=PFX ?

  3) --with options are also used to designate programs, and there are
 programs that contain plus signs in their name. Some packages have
 options
--enable-bison-regeneration
--enable-flex-regeneration
 but without the proposal they were unable to have
--enable-flex++-regeneration
 Yes, there is a program /usr/bin/flex++.

Btw, there is also a GNU package called GNU Common C++. In summary,
it is not rare to have package names and library names that contain plus
signs.

 (That ++ causes endless hassle everywhere.)

In my experience, '+' characters cause no more hassles than '-' and '.'.
Neither of these characters are globbing characters in the shell. All
three characters have a special meaning in regular expressions - but
'-' and '.' were already supported in --enable and --with options, and
known to not causes hassles.

 I'd say the opposite: allowing lots of random characters makes it
 harder for users to know/guess/remember option names.  Aside from
 technical issues with quoting and the like.

I agree that characters which interfere with shell globbing (like '?',
'*', ' ') or quoting should be avoided. But a '+' character is not
more dangerous than a '.' or '-' character.

Regarding what the users have to guess or remember:

  - For --enable-c++ you suggest to replace '+' with 'plus'.

  - Among the GCC installation options at
http://gcc.gnu.org/install/configure.html
there is an option --enable-build-with-cxx. So they decided that
replacing '+' with 'x' was the most natural.

  - The GNU Common C++ project is to be found under 'commoncpp' on
www.gnu.org and ftp.gnu.org. And there is a symlink
commonc++ - commoncpp, apparently because users would have to guess
the transliteration from '+' to 'p'.

Isn't this an indication that *not* allowing the '+' character makes
it hard for the user to guess? And that allowing the '+' character will
make it *easier* for the users?

If I can't convince you, then I would propose to be silent about this
question in the GNU standards for the moment, and revisit the issue in
five years. In five years, we'll be able to tell whether allowing a
configure option '--enable-c++' in programs will have caused hassle
everywhere.

Bruno

pitfall with AC_*_IFELSE macros

[Bruno Haible]

Hi Eric et al.,

The input of AC_COMPILE_IFELSE, AC_LINK_IFELSE, AC_RUN_IFELSE should be a
program. No one prevents a user from writing

 AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
 AC_COMPILE_IFELSE(
   [[#include fcntl.h
 int x = F_DUPFD_CLOEXEC;
   ]],
   [gl_cv_fcntl_dupfd_cloexec=yes],
   [gl_cv_fcntl_dupfd_cloexec=no])

But this code does not work: It will for example fail to detect the
presence of F_DUPFD_CLOEXEC on glibc systems. The reason is that the
test program does not see the preprocessor definitions (_GNU_SOURCE,
HAVE_* etc.) created by previous autoconf macro invocations like
gl_USE_SYSTEM_EXTENSIONS.

In other words, the first argument of AC_COMPILE_IFELSE, AC_LINK_IFELSE,
AC_RUN_IFELSE should always be an invocation of AC_LANG_SOURCE or
AC_LANG_PROGRAM, but there is nothing that enforces this.

I find that this is a major pitfall of the AC_*_IFELSE macros. [1]

What can be done about this?

Can these three macros be modified to check their first argument
unexpanded, to see whether it is an invocation of AC_LANG_SOURCE or
AC_LANG_PROGRAM, and give a warning if not?

Or can these macros be modified to check their first argument once it is
expanded, to see whether it contains the string /* end confdefs.h.  */,
and give a warning if not?

Ralf thinks [2] that one should not warn about this, and instead
only provide good documentation. But I don't think a documentation change
can address a pitfall like this, because it is so natural to use a
double-quoted program as first argument of AC_COMPILE_IFELSE. People
will not even think about this, will not realize that they need to look
up the documentation for such a seemingly simple macro use.

Can you do something about it?

Bruno


[1] http://lists.gnu.org/archive/html/bug-gnulib/2009-09/msg00042.html
[2] http://lists.gnu.org/archive/html/bug-gnulib/2010-07/msg00107.html

Re: sed --posix does not catch incomplete arguments

[Bruno Haible]

Ralf Wildenhues wrote:
  Here's what I see on Solaris 10:
  
$ echo a | sed -n -e 'i\' -e 0
Unrecognized command: 0
 
 JFTR, while i\ is a problem for some seds, I don't find any sed that rejects
   sed -e 1{ -e }
 
 among IRIX 6.5, AIX 5.1, Tru64 5.1D, BSDs, Solaris 2.6 or newer.  The problem
 seems to be relevant only for scripts ending trailing backslash (which is far
 less often a problem in sed scripts).

OK, feel free to change the wording that I submitted (doc/autoconf.texi around
line 18244).

Bruno

Re: sed --posix does not catch incomplete arguments

[Bruno Haible]

Hi,

Eric Blake reported in
http://lists.gnu.org/archive/html/bug-gnu-utils/2010-06/msg00060.html:
 The Austin group
 take this morning is that allowing -e fragments is a useful addition for
 the next revision of the standard, but that there are still
 implementations today (like AIX) that don't support it now, so it will
 be several years before sed -e 1{ -e } is standardized.

So, meanwhile, let's document the portability problem in the Autoconf
manual.

Here's what I see on Solaris 10:

  $ echo a | sed -n -e 'i\' -e 0
  Unrecognized command: 0

And on HP-UX 11:

  $ echo a | sed -n -e 'i\' -e 0
  sed: Found escape character at end of editing script.

And on AIX 4:

  $ echo a | sed -n -e 'i\' -e 0
  sed: 0602-403 0 is not a recognized function.

Here's a proposed patch.


2010-06-18  Bruno Haible  br...@clisp.org

* doc/autoconf.texi (Limitations of Usual Tools): Mention portability
problem of sed -e option with script fragments.

*** doc/autoconf.texi.orig  Fri Jun 18 14:40:10 2010
--- doc/autoconf.texi   Fri Jun 18 14:38:20 2010
***
*** 18237,18242 
--- 18237,18258 
  should use semicolon only with simple scripts that do not use these
  verbs.
  
+ The argument of the @option{-e} option must be a syntactically complete
+ script.  GNU @command{sed} allows to pass multiple script fragments,
+ each as argument of a separate @option{-e} option, that are then combined,
+ with newlines between the fragments.  A future Posix revision may allow
+ this as well.  But in Posix:2008, this is not allowed, and the
+ @command{sed} programs on Solaris 10, HP-UX 11, and AIX don't allow it
+ either:
+ 
+ @example
+ $ @kbd{echo a | sed -n -e 'i\}
+ @kbd{0'}
+ 0
+ $ @kbd{echo a | sed -n -e 'i\' -e 0}
+ Unrecognized command: 0
+ @end example
+ 
  Commands inside @{ @} brackets are further restricted.  Posix says that
  they cannot be preceded by addresses, @samp{!}, or @samp{;}, and that
  each command must be followed immediately by a newline, without any

Re: AC_FUNC_STRTOD

[Bruno Haible]

Hi Eric,

  With two old old old tests and no reasonable cross-compiling behaviour I
  would say that the best thing to do is to move these two blocks of C 
  code
  into gl_FUNC_STRTOD's test, and stop using AC_FUNC_STRTOD. Then the
  autoconf documentation can mark this macro obsolescent, and on the 
  gnulib
  side this test runs one program, not two, and we have full control over
  the cross-compilation behaviour.
 
 Or even better, why not push those two tests upstream into autoconf,
 then have gnulib override AC_FUNC_STRTOD if it detects older autoconf,
 so that everyone using upstream AC_FUNC_STRTOD can reliably detect these
 same bugs?

I don't think this would be better. The gnulib development of the last 7 years
has shown that the autoconf macro that detects bugs of a system function and
the replacement code that contains the workarounds to these bugs belong
together and are best maintained together. It makes no sense to me to put the
two files into different projects - autoconf and gnulib.

At this point, it would be a good idea to mark all AC_FUNC_* macros that
request an AC_LIBOBJ replacement as obsolete and refer the user to Gnulib
for both the macro and the workaround code (and the documentation).
Except maybe AC_FUNC_MALLOC and AC_FUNC_REALLOC, because the replacement
code for them is so trivial that anyone can make it up himself.
The affected macros are:
  - AC_FUNC_ERROR_AT_LINE
  - AC_FUNC_GETLOADAVG
  - AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
  - AC_FUNC_MEMCMP
  - AC_FUNC_MKTIME
  - AC_FUNC_OBSTACK
  - AC_FUNC_STAT, AC_FUNC_LSTAT
  - AC_FUNC_STRTOD
  - AC_FUNC_STRNLEN
  - AC_REPLACE_FNMATCH

Bruno

Re: AC_BEFORE does not warn when it should

[Bruno Haible]

Hi Gary,

 If so, then you have the arguments reversed in the second case.

Oh, I added the AC_BEFORE invocation in the second place only after I got
no warning from the AC_BEFORE invocation in the first place.

 The idiom I always use to avoid confusing the argument order is this:
 
 AC_BEFORE([$0], [warn-if-this-macro-name-was-already-called])

This is what I started with: A definition of gl_LIBUNISTRING
that starts with

  AC_BEFORE([$0], [gl_LIBUNISTRING_LIB_PREPARE])
  # XXX gl_LIBUNISTRING starts here

and a definition of gl_LIBUNISTRING_LIB_PREPARE that starts with

  # XXX gl_LIBUNISTRING_LIB_PREPARE starts here

This produced the same effects: an output order that violates the constraint,
and no warning from autoconf.

Bruno

Re: AC_LIBOBJ with file in subdirectory does not work

[Bruno Haible]

Hi Ralf,

- How to use Automake conditionals or AC_SUBSTed variables without
  file names as replacement for AC_LIBOBJ.
 
 That's fine only for projects where the list of libobjs is taken from a
 static list of file names.  Thus it may be fine for gnulib, but it is
 not something we can generally impose.

Huh? The Automake doc, under EXTRA_maude_SOURCES, says: Automake needs
to know the list of files you intend to compile _statically_. What are
the cases where you don't know that list of files, and make dist
still is able to enumerate all the files?

  I will work on the latter topic, for gnulib, in the next few days.
 
 I have looked into enabling subdir-objects for libobjs only.  That is
 not feasible.

OK.

 - Autoconf can have a new macro AC_LIBOBJS_FLATTEN or so ...

Or another idea: Extend AC_LIBOBJ so that it accepts file names with
slashes. In the configure file, replace the 2 variables LIBOBJS and
LTLIBOBJS with 4 variables LIBOBJS, LTLIBOBJS, SOLIBOBJS, LTSOLIBOBJS.
If AC_LIBOBJ([subdir/foo/bar]) is executed, then
  LIBOBJS will contain  bar.$ac_objext
  LTLIBOBJS   will contain  bar.lo
  SOLIBOBJS   will contain  subdir/foo/bar.$ac_objext
  LTSOLIBOBJS will contain  subdir/foo/bar.lo
In the Makefile.in generated by Automake from Makefile.am, generate the
lines
  LIBOBJS = @LIBOBJS@
  LTLIBOBJS = @LTLIBOBJS@
if subdir-objects is turned off, or
  LIBOBJS = @SOLIBOBJS@
  LTLIBOBJS = @LTSOLIBOBJS@
if it is turned on. Thus the LIBOBJS and LTLIBOBJS become special
Makefile variables, like srcdir, top_srcdir, and VPATH. Finally, document
that users should use $(LIBOBJS) instead of @LIBOBJS@, and $(LTLIBOBJS)
instead of @ltlibo...@.

Btw, when doing this, it would also be useful to lift the limitation to
C source files. AC_LIBOBJ can not be used for source files in C++, Fortran,
Java, Python, etc. While at it, you could introduce a macro AC_LIBOBJSOURCE
that is like AC_LIBOBJ except that its argument includes the source file
suffix:
   AC_LIBOBJSOURCE([subdir/foo/bar.c]) == AC_LIBOBJ([subdir/foo/bar])

Bruno

Re: AC_LIBOBJ with file in subdirectory does not work

[Bruno Haible]

Hi Ralf,

 Can you please tell me how to reproduce that hell in libgettextpo?

You already reproduced it pretty well.

 I tried the patch below, and so far it seems to work reasonably well.
 You lose the ability to do 'make clean' in either of
 gettext-tools/libgettextpo and gettext-tools/src without also cleaning
 the other, and some object files of the former live in the latter and
 have long names, but that's about it.  What am I missing?
 (The renaming trick is documented in the Automake manual.)
 
 Thanks,
 Ralf
 
 gettext-tools/libgettextpo/ChangeLog:
 2010-05-26  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
   * Makefile.am (AUTOMAKE_OPTIONS): Add subdir-objects.
 (libgettextpo_la_CPPFLAGS): New variable, to force renamed objects.
 
 diff --git a/gettext-tools/libgettextpo/Makefile.am 
 b/gettext-tools/libgettextpo/Makefile.am
 index 648f589..2ec49ac 100644
 --- a/gettext-tools/libgettextpo/Makefile.am
 +++ b/gettext-tools/libgettextpo/Makefile.am
 @@ -16,7 +16,7 @@
  
  ## Process this file with automake to produce Makefile.in.
  
 -AUTOMAKE_OPTIONS = 1.5 gnits no-dependencies
 +AUTOMAKE_OPTIONS = 1.5 gnits no-dependencies subdir-objects
  EXTRA_DIST =
  BUILT_SOURCES =
  MOSTLYCLEANFILES = core *.stackdump
 @@ -40,6 +40,10 @@ AM_CPPFLAGS = \
-I../src -I$(top_srcdir)/src \
-I../intl -I$(top_srcdir)/../gettext-runtime/intl
  
 +
  # libgettextpo contains the public API for PO files.
  libgettextpo_la_SOURCES = \
gettext-po.c \
 
 

Re: AC_LIBOBJ with file in subdirectory does not work

[Bruno Haible]

Hi Ralf,

 Can you please tell me how to reproduce that hell in libgettextpo?

You reproduced it already pretty well.

 +# Ensure objects in ../src are renamed so they don't conflict with
 +# the objects generated from ../src/Makefile.
 +libgettextpo_la_CPPFLAGS = $(AM_CPPFLAGS)

Wow. What a hack! Even with the comments, I could not understand how
changing CPPFLAGS could have an effect on object files.

 I tried the patch below, and so far it seems to work reasonably well.
 You lose the ability to do 'make clean' in either of
 gettext-tools/libgettextpo and gettext-tools/src without also cleaning
 the other, ..., but that's about it.

That's about it. ;-)

Thank you for spending time on experiments how to make libgettextpo work
reasonably well with 'subdir-objects'. But, frankly, IMO the effort
should go in the opposite direction:
  - How to continue to offer 'subdir-objects' as a choice that remains
entirely an unconstrained choice.
  - How to use Automake conditionals or AC_SUBSTed variables without
file names as replacement for AC_LIBOBJ.

I will work on the latter topic, for gnulib, in the next few days.

Bruno

Re: AC_LIBOBJ with file in subdirectory does not work

[Bruno Haible]

[Adding bug-autoconf. This is a reply to
 http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/4917.]

Hi Ralf,

 Autoconf code knows nothing about the Automake subdir-objects option
 (and what's more, that option may vary between different Makefile.am
 files).

Exactly, that's the main stumbling point. When I have a file foo/bar.c,
I don't know whether my macros should expand to AC_LIBOBJ([foo/bar])
or AC_LIBOBJ([bar]). configure has no knowledge about the Automake
options specified in specific Makefile.am files.

 I see a few possible alternative ways out:
 - Automake requires subdir-objects if you put slashes into $LIBOBJS,

There are cases where the developer does not want 'subdir-objects'.
I'm having the problem with AC_LIBOBJ in the gettext/gettext-tools/libgettextpo
directory, and when I enable 'subdir-objects' in this directory, all hell
breaks loose. Impossible.

 - Autoconf optionally removes dirname parts from $LIBOBJS (i.e., some
   kind of subdir-objects toggle for Autoconf),

Yes, but that requires Autoconf to receive information from Automake about
its options. Which is hard because there are several Makefile.ams in the
scope of a single configure file.

And it would be wrong design to have information from Automake flow back into
configure. Autoconf is made for detecting platform dependencies, Automake
is made for managing source files and their compilation. Therefore Autoconf
is naturally a base layer for Automake, not the other way around.

 - Automake always enables subdir-objects machinery for the $LIBOBJS
   files, but not necessarily for the other files.

This would be acceptable, yes.

The other, completely different alternative is to deprecate AC_LIBOBJ.
AC_LIBOBJ is a misdesign already from the beginning, because it stuffs
file names - which belong in Makefiles - into configure files, where they
don't belong. This causes no end of maintainability problems. Instead of

  if some-test; then
AC_LIBOBJ([foo/bar])
  fi

you can recommend users to write

  foo_bar_value=false
  if some-test; then
foo_bar_value=true
  fi
  AM_CONDITIONAL([FOO_BAR], [$foo_bar_value])

and in Makefile.am

  if FOO_BAR
  prog_SOURCES += foo/bar.c
  endif

or for a library

  if FOO_BAR
  library_la_SOURCES += foo/bar.c
  endif

And voilà - no more need to worry about 'subdir-objects'. No more need to
define an EXTRA_prog_SOURCES variable. Even no need any more to invoke
AC_CONFIG_LIBOBJ_DIR. All these advantages, by following one simple rule:

 ╭───╮
 │ Don't put file names into configure.  │
 │ Let Automake, and only Automake, handle source and object file names. │
 ╰───╯

Bruno

Re: feature request: allow plus signs in AC_ARG_ENABLE

[Bruno Haible]

Ralf Wildenhues wrote:
 Those semantics already have users out there, though.  For example GCC
 relies on --disable-libstdc___v3, so this would be an incompatible
 change.

OK, the name of the variable is not important to me (the user can define
his own variable anyway). Here's a revised patch:


2010-03-13  Bruno Haible  br...@clisp.org

* doc/autoconf.texi (External Software): Mention that AC_ARG_WITH
accepts packages with a + sign in it.
(Package Options): Likewise for AC_ARG_ENABLE.
* lib/autoconf/general.m4 (_AC_ENABLE_IF): Also replace '+' with '_'.

--- doc/autoconf.texi.orig  Sat Mar 13 21:48:56 2010
+++ doc/autoconf.texi   Sat Mar 13 21:48:51 2010
@@ -20491,7 +20491,7 @@
 @var{action-if-given}.  If neither option was given, run shell commands
 @var{action-if-not-given}.  The name @var{package} indicates another
 software package that this program should work with.  It should consist
-only of alphanumeric characters, dashes, and dots.
+only of alphanumeric characters, dashes, plus signs, and dots.
 
 The option's argument is available to the shell commands
 @var{action-if-given} in the shell variable @code{withval}, which is
@@ -20643,7 +20643,7 @@
 shell commands @var{action-if-given}.  If neither option was given, run
 shell commands @var{action-if-not-given}.  The name @var{feature}
 indicates an optional user-level facility.  It should consist only of
-alphanumeric characters, dashes, and dots.
+alphanumeric characters, dashes, plus signs, and dots.
 
 The option's argument is available to the shell commands
 @var{action-if-given} in the shell variable @code{enableval}, which is
--- lib/autoconf/general.m4.origSat Mar 13 21:48:56 2010
+++ lib/autoconf/general.m4 Sat Mar 13 21:44:11 2010
@@ -1440,7 +1440,7 @@
 #
 m4_define([_AC_ENABLE_IF],
 [...@%:@ Check whether --$1-$2 was given.
-_AC_ENABLE_IF_ACTION([$1], m4_translit([$2], [-.], [__]), [$3], [$4])
+_AC_ENABLE_IF_ACTION([$1], m4_translit([$2], [-+.], [___]), [$3], [$4])
 ])
 
 m4_define([_AC_ENABLE_IF_ACTION],

Re: MKDIR_P discovered by configure but not substituted in the Makefile

[Bruno Haible]

Eric Blake wrote:
  automake (GNU automake) 1.9.6
 
 There's your problem. It's time for an upgrade ...

Upgrading autoconf instead of automake would also help. James' problem
  - can be reproduced with automake 1.9.6, autoconf 2.61,
  - is corrected  with automake 1.9.6, autoconf 2.62 .. 2.65,
  - is corrected  with automake 1.10,  autoconf 2.60 .. 2.65.

The reason is that the definition of AC_PROG_MKDIR_P in autoconf 2.62 has
this piece of code:

  dnl status.m4 does special magic for MKDIR_P instead of AC_SUBST,
  dnl to get relative names right.  However, also AC_SUBST here so
  dnl that Automake versions before 1.10 will pick it up (they do not
  dnl trace AC_SUBST_TRACE).
  dnl FIXME: Remove this once we drop support for Automake  1.10.
  AC_SUBST([MKDIR_P])dnl

but autoconf 2.61 does not have it. I'm applying this fix to gnulib:


2010-02-20  Bruno Haible  br...@clisp.org

Restore support for automake 1.9.6 with autoconf 2.61.
* m4/gnulib-common.m4 (AC_PROG_MKDIR_P): Ensure MKDIR_P is AC_SUBSTed.
Reported by James Youngman j...@gnu.org.

--- m4/gnulib-common.m4.origSun Feb 21 03:27:01 2010
+++ m4/gnulib-common.m4 Sun Feb 21 03:26:48 2010
@@ -1,4 +1,4 @@
-# gnulib-common.m4 serial 12
+# gnulib-common.m4 serial 13
 dnl Copyright (C) 2007-2010 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -61,9 +61,16 @@
 [AS_IF([test xAS_VAR_GET([$1]) = x$2], [$3], [$4])])])
 
 # AC_PROG_MKDIR_P
-# is a backport of autoconf-2.60's AC_PROG_MKDIR_P.
-# Remove this macro when we can assume autoconf = 2.60.
-m4_ifdef([AC_PROG_MKDIR_P], [], [
+# is a backport of autoconf-2.60's AC_PROG_MKDIR_P, with a fix
+# for interoperability with automake-1.9.6 from autoconf-2.62.
+# Remove this macro when we can assume autoconf = 2.62 or
+# autoconf = 2.60  automake = 1.10.
+m4_ifdef([AC_PROG_MKDIR_P], [
+  dnl For automake-1.9.6  autoconf  2.62: Ensure MKDIR_P is AC_SUBSTed.
+  m4_define([AC_PROG_MKDIR_P],
+m4_defn([AC_PROG_MKDIR_P])[
+AC_SUBST([MKDIR_P])])], [
+  dnl For autoconf  2.60: Backport of AC_PROG_MKDIR_P.
   AC_DEFUN_ONCE([AC_PROG_MKDIR_P],
 [AC_REQUIRE([AM_PROG_MKDIR_P])dnl defined by automake
  MKDIR_P='$(mkdir_p)'

[GNU Autoconf 2.65] testsuite: 35 failed

[Bruno Haible]

Building autoconf 2.65 gives a test failure for me.
On Linux/x86_64:
$ ./configure --host=i686-pc-linux-gnu 
--prefix=/arch/x86-linux/gnu-inst-autoconf/2.65 CC=gcc -m32 -march=i586 
CXX=g++ -m32 -march=i586 LDFLAGS=-m32 CPPFLAGS=-Wall
...
$ make
...
$ make check
...
 35: autom4te cache creation FAILED (tools.at:1194)
...

Find attached the testsuite.log file.

When I remove the $HOME/.autom4te.cfg file in my home directory, the test 
passes.

This fixes the failure for me (workaround copied from test #34):


2009-11-21  Bruno Haible  br...@clisp.org

* tests/tools.at (autom4te cache creation): Skip the test if the user 
has a
.autom4te.cfg file.

*** autoconf-2.65.orig/tests/tools.at   2009-11-05 03:32:16.0 +0100
--- autoconf-2.65/tests/tools.at2009-11-22 02:44:31.0 +0100
***
*** 1173,1178 
--- 1173,1180 
  # or create files there.
  AT_SETUP([autom4te cache creation])
  
+ AT_CHECK([test ! -f $HOME/.autom4te.cfg || exit 77], [], [ignore], [ignore])
+ 
  # Work in a subdirectory so autotest can scribble in the toplevel.
  mkdir sub
  chmod a-w sub



= testsuite.log 
=
## - ##
## GNU Autoconf 2.65 test suite. ##
## - ##

testsuite: command line was:
  $ ./testsuite 

## --- ##
## ChangeLogs. ##
## --- ##

testsuite: ../ChangeLog:
| 2009-11-21  Eric Blake  e...@byu.net
| 
|   Release Version 2.65.
|   * NEWS: Mention the release.
| 
|   Prepare for release.
|   * build-aux/announce-gen: Sync from upstream.
|   * build-aux/config.guess: Likewise.
|   * build-aux/config.sub: Likewise.
|   * cfg.mk (gnu_rel_host, url_dir_list): Move...

## - ##
## Platform. ##
## - ##

hostname = linuix
uname -m = x86_64
uname -r = 2.6.25.20-0.5-default
uname -s = Linux
uname -v = #1 SMP 2009-08-14 01:48:11 +0200

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = x86_64
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/bruno/data/build/autoconf-2.65/tests
PATH: /opt/kde3/bin
PATH: /home/bruno/bin
PATH: /arch/x86_64-linux/gnu/bin
PATH: /arch/x86-linux/gnu/bin
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/bin/X11
PATH: /usr/X11R6/bin
PATH: /usr/games
PATH: /usr/lib64/jvm/jre/bin
PATH: /usr/lib/mit/bin
PATH: /usr/lib/mit/sbin

testsuite: atconfig:
| # Configurable variable values for building test suites.
| # Generated by ./config.status.
| # Copyright (C) 2009 Free Software Foundation, Inc.
| 
| # The test suite will define top_srcdir=/../.. etc.
| at_testdir='tests'
| abs_builddir='/home/bruno/data/build/autoconf-2.65/tests'
| at_srcdir='.'
| abs_srcdir='/home/bruno/data/build/autoconf-2.65/tests'
| at_top_srcdir='..'
| abs_top_srcdir='/home/bruno/data/build/autoconf-2.65'
| at_top_build_prefix='../'
| abs_top_builddir='/home/bruno/data/build/autoconf-2.65'
| 
| # Backward compatibility with Autotest = 2.59b:
| at_top_builddir=$at_top_build_prefix
| 
| AUTOTEST_PATH='tests'
| 
| SHELL=${CONFIG_SHELL-'/bin/sh'}

testsuite: atlocal:
| # -*- shell-script -*-
| # tests/atlocal.  Generated from atlocal.in by configure.
| # Configurable variable values for Autoconf test suite.
| 
| # Copyright (C) 2000, 2001, 2005, 2008, 2009 Free Software Foundation,
| # Inc.
| #
| # This program is free software: you can redistribute it and/or modify
| # it under the terms of the GNU General Public License as published by
| # the Free Software Foundation, either version 3 of the License, or
| # (at your option) any later version.
| #
| # This program is distributed in the hope that it will be useful,
| # but WITHOUT ANY WARRANTY; without even the implied warranty of
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
| # GNU General Public License for more details.
| #
| # You should have received a copy of the GNU General Public License
| # along with this program.  If not, see http://www.gnu.org/licenses/.
| 
| PERL='/usr/bin/perl'
| GREP='/arch/x86-linux/gnu/bin/grep'
| EGREP='/arch/x86-linux/gnu/bin/grep -E'
| SED='/arch/x86_64-linux/gnu/bin/sed'
| 
| # We need to know if sh -n is ok.
| ac_cv_sh_n_works='yes'
| 
| # Check whether the underlying system can manage some unusual
| # symbols in file names.
| if test -z ''; then
|   func_sanitize_file_name () { echo $@; }
| else
|   func_sanitize_file_name () { echo $@ | tr -d ''; }
| fi
| 
| # Can we create directories with trailing whitespaces in their name?
| ac_cv_dir_trailing_space='yes'
| if test $ac_cv_dir_trailing_space = yes; then
|   func_sanitize_dir_name () { echo $@; }
| else
|   func_sanitize_dir_name () { echo $@ | sed 's/  *$//'; }
| fi

##  ##
## Tested programs

document how to override test results

[Bruno Haible]

Hi,

It would be good if the autoconf documentation would state how to override
the results of autoconf macros (without actually changing the autoconf
macros and rebuilding the configure file).

This question has come up on the gnulib list. I think the answer is as
follows, but it's not documented in the autoconf manual: If a building
user wants to override some values of variables determined by autoconf, he
should do that by setting the particular cache variable name while
(re-)running configure, *not* by passing the modified variable values to
'make'. The reasons are:
  1) Some variables are substituted into other files than Makefiles.
  2) Some other AC_SUBSTed variable values may depend on the guessed ones.
  3) When recursing into subdirectories, variables passed on the
 command line are not necessarily passed to subdirectory 'make' runs.
 (GNU make and BSD make do this, but Solaris make does not.)

Jim Meyering also says in [1]:
   developers seem relatively used to tracing through Makefile*, but
   those new to autoconf do not always know to look in config.status.

I cannot find this doc under Manual Configuration nor Site Configuration.

Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2009-09/msg4.html

Re: document how to override test results

[Bruno Haible]

Ralf Wildenhues wrote:
 the user
 will prefer the simplest and fastest way to get over a build failure.

So, please document the possible ways of getting over a build failure.
Currently, the manual is silent about this.

 I think it would be better if Automake stated plainly:
 
Prefer using $(variable) over @varia...@.  That enables the user
to override the setting of the variable at `make' run time.
 
 I thought the manual already said this, but I can't find it right now.

This is only a partial answer to the problem. It helps only if one of
the AC_PROG_*, AC_CHECK_PROG*, AC_CHECK_TOOL* macros guessed wrong.

What if the user wants to override the results of the following
autoconf tests?
  - AC_CHECK_TYPES([uid_t])
  - AC_CHECK_LIB([nsl], [gethostname])
  - AC_FUNC_GETGROUPS
  - AC_FUNC_MKTIME
  - AC_CHECK_FUNC([foo])
  - AC_REPLACE_FUNCS([foo])
  - AC_CHECK_HEADER([stdbool.h])
  - AC_CHECK_DECL([errno],,,[#include errno.h])
  - AC_CHECK_MEMBER([struct stat.st_blksize])
  - AC_SYS_LARGEFILE
  - AC_CANONICAL_HOST

Currently only a few autoconf wizards know how to do it. The doc does
not say it.

Bruno

another doc update about Solaris 'tr'

[Bruno Haible]

Hi,

Just noticed that the problem with tr '\0' '~' is not really with the
'\0' argument, but with the NUL bytes in the input. This version of 'tr'
discards NUL bytes in the input even when not asked to do so. It occurs
with tr x x but also with tr -d '\r'. Here is a suggested doc update.

Also, a mention that using /usr/xpg6/bin/tr might be preferable to
/usr/xpg4/bin/tr, when it exists. It supports the '-C' option, the
latter doesn't.


2009-08-30  Bruno Haible  br...@clisp.org

* doc/autoconf.texi (Limitations of Usual Tools): Mention that Solaris
/usr/bin/tr does not only have problems with replacing NUL bytes but
discards all NUL bytes from the input.

--- doc/autoconf.texi.orig  2009-08-31 01:16:01.0 +0200
+++ doc/autoconf.texi   2009-08-31 01:12:38.0 +0200
@@ -17815,16 +17815,21 @@
 
 Posix requires @command{tr} to operate on binary files.  But at least
 Solaris @command{/usr/ucb/tr} and @command{/usr/bin/tr} still fail to
-handle @samp{\0} as the octal escape for @code{NUL}.  On Solaris, when
-using @command{tr} to neutralize a binary file by converting @code{NUL}
-to a different character, it is necessary to use
-...@command{/usr/xpg4/bin/tr} instead.
+handle @samp{\0} as the octal escape for @code{NUL}; these programs
+always discard all @code{NUL} bytes from the input.  On Solaris, when
+using @command{tr} to process a binary file that may contain @code{NUL}
+bytes, it is necessary to use @command{/usr/xpg4/bin/tr} instead, or
+...@command{/usr/xpg6/bin/tr} if that is available.
 
 @example
 $ @kbd{printf 'a\0b\n' | /usr/ucb/tr '\0' '~' | wc -c}
 3
 $ @kbd{printf 'a\0b\n' | /usr/xpg4/bin/tr '\0' '~' | wc -c}
 4
+$ @kbd{printf 'a\0b\n' | /usr/ucb/tr x x | wc -c}
+3
+$ @kbd{printf 'a\0b\n' | /usr/xpg4/bin/tr x x | wc -c}
+4
 @end example
 
 @end table

Re: update doc about Solaris 'tr'

[Bruno Haible]

Ralf Wildenhues wrote:
  On a Solaris 10 machine, I happened to not have /usr/xpg4/bin in front of
  /usr/bin in my PATH. Consequence: The 'tr' program does not recognize
  the POSIX (and BSD) syntax for character ranges.
 
 You can work around it by using the System V way of writing ranges:
   tr '[a-z]' '[A-Z]'
 
 which will work with both types of tr programs for this range.

True. But I prefer (and recommend) the follow the standards policy.
In other words, I find it better to write my code according to the POSIX
standard, and choose tools that follow the POSIX standard, than to
write code in randomly annotated/hacked ways, so that non-POSIX tools
with museum value can be accommodated. For two reasons:
  - Future code maintainers may wonder why I explicitly ask to transform
'[' into '[' and ']' into ']' and optimize this away.
  - Random hacks have a tendency of becoming mutually incompatible. Try to
put 3 or 5 random hacks in the same place, sometimes there's no way out.

If there was no /usr/xpg4/bin/tr on Solaris, then of course the situation
would be different, then one could only recommend
   tr '[a-z]' '[A-Z]'
or
   tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ

Bruno

race condition in AC_PROG_CC?

[Bruno Haible]

Hi,

Just got this error message while executing gettext's configure (built with
autoconf-2.64) on Cygwin 1.5.25:


$ ./configure --prefix=/usr/local/cygwin CPPFLAGS=-I/usr/local/cygwin/include 
-Wall LDFLAGS=-L/usr/local/cygwin/lib --enable-shared
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
configure: creating ./config.status
config.status: creating Makefile
config.status: creating gnulib-local/Makefile
=== configuring in autoconf-lib-link 
(/home/bruno/gettext-0.18-pre1-cygwin-shared/autoconf-lib-link)
configure: running /bin/sh ./configure --disable-option-checking 
'--prefix=/usr/local/cygwin'  'CPPFLAGS=-I/usr/local/cygwin/include -Wall' 
'LDFLAGS=-L/usr/local/cygwin/lib' '--enable-shared' --cache-file=/dev/null 
--srcdir=.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... 
sed: can't read conftest.c: No such file or directory
configure: error: in 
`/home/bruno/gettext-0.18-pre1-cygwin-shared/autoconf-lib-link':
configure: error: C compiler cannot create executables
See `config.log' for more details.
configure: error: ./configure failed for autoconf-lib-link


The autoconf-lib-link/config.log contains this snippet:


## --- ##
## Core tests. ##
## --- ##

configure:3112: gcc  -I/usr/local/cygwin/include -Wall -L/usr/local/cygwin/lib 
conftest.c  5
gcc: conftest.c: No such file or directory
gcc: no input files
configure:3116: $? = 1
configure:3153: result:
configure: failed program was:
configure:3159: error: in 
`/home/bruno/gettext-0.18-pre1-cygwin-shared/autoconf-lib-link':
configure:3163: error: C compiler cannot create executables
See `config.log' for more details.


When I retried this same command, it worked fine. At the moment when it failed,
I was running 4 different configure scripts (each in its own separate directory)
in parallel.

I cannot believe that Cygwin would mix up things when creating two conftest.c
files in different directories at the same time. So is it a race condition in
the configure expansion of AC_PROG_CC?

When a Cygwin machine is overloaded, the symptoms are usually different:
  513776218 [main] sh 7548 fork: child -1 - died waiting for longjmp before 
initialization, retry -1, exit code 0xC142, errno 11
  ./configure: fork: Resource temporarily unavailable
and similar. (I tested this by running 100 configures in parallel.)

Bruno

Re: ac_vpsub quoting problem

[Bruno Haible]

Ralf Wildenhues wrote:
 Reason is that sed (and POSIX BRE in
 general) treat ^ and $ anchors only as special at the beginning resp.
 end of the BRE, and maybe at subexpression boundaries; elsewhere, they
 both match literal ^ and $ characters.

Indeed. That's documented in POSIX. Sorry for the false alarm.

Bruno

Re: tweak for documentation of how to create universal binaries

[Bruno Haible]

Ralf Wildenhues wrote:
 Well, if Bruno has run the latter command only (without going through
 the depcomp wrapper), and got inconsistent results, then that indicates
 a bug in this gcc.

Yes, the command that I ran 1000 times was the gcc command that produces
the *.TPo file.

 AIUI, the nature of the issue seems to be that one process scribbles
 into the file already written to by another process.

Yes. Or that two processes (or two threads) write to the same file at the
same time, through two different file descriptors.

 Unless this 
 particular gcc version has a switch to disable -MD for one of the two
 compilations, or direct the output elsewhere without a race,

I don't see such a flag in Apple gcc's documentation.

 then we may 
 still be able to exploit the fact that the output by the second process
 ends in a newline without backslash.

Yes, this should be possible.

Other alternatives would be to run the gcc command twice, once with a
single -arch option only to produce the .TPo file, and once with all
-arch options and without -MD, to produce the object file. But doubling
the compilation times will not sit with most people. Then people will
really prefer --disable-dependency-tracking.

Or to repeat the gcc command if and only if the generated .TPo file is
malformed. The performance overhead of doing this should be small.

 +  -e 's/^['$alpha']:\/[^:]*: / /' \
 +  -e '$!s/[^\\]$/\\/' ' $tmpdepfile  $depfile

The last line has an odd number of single-quotes. If I remove the last
extraneous single-quote, what it does in my particular case is to produce
a file that ends in

  /usr/include/string.h unictype/test-predicate-part2.h\
lib/string.h \
  /usr/include/string.h unictype/test-predicate-part2.h

which will cause make to complain about a nonexistent file
'lib/string.h':

make[3]: *** No rule to make target `lib/string.h', needed by 
`unictype/test-categ_Nl.o'.  Stop.

IMO, depcomp must ignore everything past the first non-backslashed
newline - or must ignore the generated .TPo file altogether.

Bruno

tweak for documentation of how to create universal binaries

[Bruno Haible]

Hi,

On 2008-08-17, we discussed what to write in INSTALL about the creation
of multi-arch binaries on MacOS X. In [1] Peter O'Gorman wrote:

 For automake using projects --disable-dependency-tracking is also
 necessary.

I didn't want to believe it, because I could not reproduce any problem with
texinfo-4.12. But now I reproduce the problem with a libunistring snapshot:

$ ./configure CC=gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64  CXX=g++ 
-arch i386 -arch x86_64 -arch ppc -arch ppc64 CPP=gcc -E CXXCPP=g++ -E
$ make
$ make check
...
unictype/.deps/test-pr_bidi_common_separator.Po:30: *** missing separator.  
Stop.
make: *** [check-recursive] Error 1

That .Po file contains Makefile dependencies with invalid syntax:

unictype/test-pr_bidi_common_separator.o : \
  \
 unictype/test-pr_bidi_common_separator.c unictype/test-predicate-part1.h \
  ../config.h ../lib/unictype.h ../lib/unitypes.h \
  ../lib/unistring-stdint.h ../lib/stdint.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/stdint.h \
  /usr/include/sys/types.h /usr/include/sys/appleapiopts.h \
  /usr/include/sys/cdefs.h /usr/include/machine/types.h \
  /usr/include/ppc/types.h /usr/include/ppc/_types.h \
  /usr/include/sys/_types.h /usr/include/machine/_types.h \
  /usr/include/machine/endian.h /usr/include/ppc/endian.h \
  /usr/include/sys/_endian.h /usr/include/sys/_structs.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/limits.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/syslimits.h \
  /usr/include/limits.h /usr/include/machine/limits.h \
  /usr/include/ppc/limits.h /usr/include/ppc/_limits.h \
  /usr/include/sys/syslimits.h /usr/include/inttypes.h \
  /usr/include/_types.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/syslimits.h \
  ../lib/unistring-stdbool.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/stdbool.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/stddef.h \
  /usr/include/stdio.h ../lib/stdlib.h /usr/include/stdlib.h \
  /usr/include/available.h /usr/include/sys/wait.h \
  /usr/include/sys/signal.h /usr/include/machine/signal.h \
  /usr/include/ppc/signal.h /usr/include/ppc/_structs.h \
  /usr/include/machine/_structs.h /usr/include/mach/ppc/_structs.h \
  /usr/include/sys/resource.h ../lib/alloca.h ../lib/string.h \
  /usr/include/string.h unictype/test-predicate-part2.h
lib/string.h \
  /usr/include/string.h unictype/test-predicate-part2.h
unictype/test-pr_bidi_common_separator.c :

Maybe the problem occurs only with large packages that use libtool.
In any case, the problem goes away by specifying --disable-dependency-tracking.
I propose to enhance the recommendation:


2009-04-10  Bruno Haible  br...@clisp.org

* doc/install.texi (Multiple Architectures): Recommend to use
--disable-dependency-tracking.
Suggested by Peter O'Gorman pe...@pogma.com.

--- doc/install.texi.bak2009-04-10 00:43:23.0 +0200
+++ doc/install.texi2009-04-10 22:09:07.0 +0200
@@ -125,12 +125,14 @@
 executables that work on multiple system types---known as @dfn{fat} or
 @dfn{universal} binaries---by specifying multiple @option{-arch} options
 to the compiler but only a single @option{-arch} option to the
-preprocessor.  Like this:
+preprocessor.  Also, automatic dependency tracking needs to be disabled
+in this case.  Like this:
 
 @example
 ./configure CC=gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64 \
 CXX=g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64 \
-CPP=gcc -E CXXCPP=g++ -E
+CPP=gcc -E CXXCPP=g++ -E \
+--disable-dependency-tracking
 @end example
 
 This is not guaranteed to produce working output in all cases, you may



[1] http://lists.gnu.org/archive/html/autoconf/2008-08/msg00045.html

Re: tweak for documentation of how to create universal binaries

[Bruno Haible]

Ralf Wildenhues wrote:
 I would like to veto this patch, and in general the mentality of hacking
 around further away from the root of the problem than is necessary.
 
 How about trying to fix it instead of this?

You want to know the root of the problem? Here it is: The automake generated
Makefile executed the command

source='unictype/test-categ_Nl.c' object='unictype/test-categ_Nl.o' libtool=no \
DEPDIR=.deps depmode=gcc /bin/sh ../build-aux/depcomp \
gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64 -DHAVE_CONFIG_H \
-I. -I..  -I. -I. -I.. -I./.. -I../lib -I./../lib   -g -O2 -c \
-o unictype/test-categ_Nl.o unictype/test-categ_Nl.c

which invokes the command

gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64 -DHAVE_CONFIG_H \
-I. -I.. -I. -I. -I.. -I./.. -I../lib -I./../lib -g -O2 -c \
-o unictype/test-categ_Nl.o unictype/test-categ_Nl.c \
-Wp,-MD,unictype/.deps/test-categ_Nl.TPo

This command produces the file unictype/.deps/test-categ_Nl.TPo. Ususally
the result is the attached file marked good, but sometimes the result
is the attached file marked bad.

I ran this command 1000 times, and got
  - 668 times a valid result that refers to system include files in
/usr/lib/gcc/powerpc-apple-darwin9/,
  - 329 times a valid result that refers to system include files in
/usr/lib/gcc/i686-apple-darwin9/,
  - 3 times the bad result.

The bad result has the same file size as the i686 result but its
contents is the powerpc result, filled up with the tail of the
i686 result. See:
  $ ls -l test-categ_Nl.TPo-*   
  -rw-r--r-- 1 bruno staff 1627 Apr 11 01:05 test-categ_Nl.TPo-bad
  -rw-r--r-- 1 bruno staff 1627 Apr 11 01:07 test-categ_Nl.TPo-i686
  -rw-r--r-- 1 bruno staff 1556 Apr 11 01:07 test-categ_Nl.TPo-powerpc
  $ diff -u test-categ_Nl.TPo-powerpc test-categ_Nl.TPo-bad 
  --- test-categ_Nl.TPo-powerpc   2009-04-11 01:07:16.0 +0200
  +++ test-categ_Nl.TPo-bad   2009-04-11 01:05:12.0 +0200
  @@ -25,3 +25,5 @@
 /usr/include/machine/_structs.h /usr/include/mach/ppc/_structs.h \
 /usr/include/sys/resource.h ../lib/alloca.h ../lib/string.h \
 /usr/include/string.h unictype/test-predicate-part2.h
  +lib/string.h \
  +  /usr/include/string.h unictype/test-predicate-part2.h

gcc is /usr/bin/gcc, which identifies itself as
gcc version 4.0.1 (Apple Inc. build 5465).

How do you want to fix this bug?

When a fix is clearly out of reach, documenting a workaround is not only
adequate; it is even our duty towards the users.

Bruno


test-categ_Nl.o: unictype/test-categ_Nl.c unictype/test-predicate-part1.h \
  ../config.h ../lib/unictype.h ../lib/unitypes.h \
  ../lib/unistring-stdint.h ../lib/stdint.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/stdint.h \
  /usr/include/sys/types.h /usr/include/sys/appleapiopts.h \
  /usr/include/sys/cdefs.h /usr/include/machine/types.h \
  /usr/include/ppc/types.h /usr/include/ppc/_types.h \
  /usr/include/sys/_types.h /usr/include/machine/_types.h \
  /usr/include/machine/endian.h /usr/include/ppc/endian.h \
  /usr/include/sys/_endian.h /usr/include/sys/_structs.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/limits.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/syslimits.h \
  /usr/include/limits.h /usr/include/machine/limits.h \
  /usr/include/ppc/limits.h /usr/include/ppc/_limits.h \
  /usr/include/sys/syslimits.h /usr/include/inttypes.h \
  /usr/include/_types.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/syslimits.h \
  ../lib/unistring-stdbool.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/stdbool.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/stddef.h \
  /usr/include/stdio.h ../lib/stdlib.h /usr/include/stdlib.h \
  /usr/include/available.h /usr/include/sys/wait.h \
  /usr/include/sys/signal.h /usr/include/machine/signal.h \
  /usr/include/ppc/signal.h /usr/include/ppc/_structs.h \
  /usr/include/machine/_structs.h /usr/include/mach/ppc/_structs.h \
  /usr/include/sys/resource.h ../lib/alloca.h ../lib/string.h \
  /usr/include/string.h unictype/test-predicate-part2.h
lib/string.h \
  /usr/include/string.h unictype/test-predicate-part2.h
test-categ_Nl.o: unictype/test-categ_Nl.c unictype/test-predicate-part1.h \
  ../config.h ../lib/unictype.h ../lib/unitypes.h \
  ../lib/unistring-stdint.h ../lib/stdint.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/stdint.h \
  /usr/include/sys/types.h /usr/include/sys/appleapiopts.h \
  /usr/include/sys/cdefs.h /usr/include/machine/types.h \
  /usr/include/ppc/types.h /usr/include/ppc/_types.h \
  /usr/include/sys/_types.h /usr/include/machine/_types.h \
  /usr/include/machine/endian.h /usr/include/ppc/endian.h \
  /usr/include/sys/_endian.h /usr/include/sys/_structs.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/limits.h \
  /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/syslimits.h \
  /usr/include/limits.h /usr/include/machine/limits.h \
  /usr/include/ppc/limits.h /usr/include/ppc/_limits.h \
  

Re: autoconf: undocumented limitation

[Bruno Haible]

Ralf Wildenhues wrote:
 Are you complaining that the limitation of 'awk' is not documented, or
 that the limitation of 'config.status' is not documented?

Actually, both. The limitation of 'awk' can be documented in section
Limitations of Usual Tools, and the limitation about config.status
should be mentioned in the documentation of AC_CONFIG_FILES.

 If the 
 latter, then no, I don't think we should document that.  We should just
 document that config.status works only on text files, i.e., the line
 length is limited to LINE_MAX

Saying only text files would not be sufficient. The same long line
in a .m4 file is supported without problems; these are also text files.

Please say that the line length is limited. But what is LINE_MAX? If you
mean LINE_MAX from limits.h [1], then such a statement is useless,
because this value is platform dependent, and a reference to POSIX [2]
does not help because HP-UX 11.00 and IRIX 6.5 are far away from POSIX
compliance.

 Actually, we should fix config.status if somebody sees a portable way.
 sed only gets us to 4000 bytes which I don't think is worth the hassles
 of pre- and postprocessing the stuff we feed through awk; and sh read -r
 is not portable enough.

I agree that it's too much hassles. The limitation is harmless for files
that are written manually, but can hurt for generated files. The developers
of tools that generate such files (gnulib-tool, in this case, but also
automake) need to be able to know about this limitation.

Bruno


[1] http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
[2] http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap01.html

autoconf: undocumented limitation

[Bruno Haible]

Hi,

Files that are used as arguments of AC_CONFIG_FILES must have a maximum line
length (not counting the newline) of at most 3070. This limitation is not
documented in the autoconf manual. Could you please document it?

Past this limit, config.status fails on HP-UX 11.00 and IRIX 6.5.


On HP-UX 11.00:
-
config.status: creating lib/Makefile
awk: Input line # Reproduce by: gnul cannot be longer than 3,000 bytes.
 The input line number is 25.
 The source line number is 437.
config.status: error: could not create lib/Makefile
-

It works with line length 3070, fails with line length 3071.


On IRIX 6.5:
-
config.status: creating lib/Makefile
Input record `# Reproduce by: gnul...' too long
Input record number 25
Source line number 437
config.status: error: could not create lib/Makefile
-

It works with line length 3071, fails with line length 3072.


Bruno

ac_vpsub quoting problem

[Bruno Haible]

Hi,

A config.status created for gettext-tools by autoconf 2.63 on normal Linux
contains these lines:

ac_sed_extra=/^[]*VPATH[]*=/{
s/:*\$(srcdir):*/:/
s/:*\${srcdir}:*/:/
s/:*...@srcdir@:*/:/
s/^\([^=]*=[ ]*\):*/\1/
s/:*$//
s/^[^=]*=[   ]*$//
}
...

The two lines with (srcdir) are pointless because they can never match:
the \$ gets transformed to simple $ by the shell's transformation of
double-quoted strings, and in the regular expression it then denotes the
end of line.

This comes from status,m4, around line 660:

cat $CONFIG_STATUS _ACEOF || ac_write_fail=1
ac_sed_extra=$ac_vpsub
$extrasub
_ACEOF

Possible fixes are:

  - Double every backslash in the definition of ac_vpsub,

  - Enclose the reference to ac_vpsub in single-quotes:

cat $CONFIG_STATUS _ACEOF || ac_write_fail=1
ac_sed_extra='$ac_vpsub'
$extrasub
_ACEOF

Bruno

Re: ac_vpsub quoting problem

[Bruno Haible]

Hello Ralf,

 do you need these two lines to work?

No, I don't have a test case for this. I spotted it only while looking at
config.status in a text editor with syntax colouring.

Bruno