Re: Improve Autoconf MSVC support

[Nick Bowler]

On 2024-06-03 16:19, Antonin Décimo wrote:
>> I guess you are not using Automake, because both of these problems
>> should be solved automatically by Automake.  Automake replaces $CC
>> with invocations through a wrapper script that knows how to translate
>> -l and -o options into MSVC equivalents (such as -Fo/-Fe).
>>
>> If you don't want to use Automake I suggest at least using this
>> wrapper script in your project.
> 
> I'm not using Automake but I'll consider it. Were you referring to cccl?

No, Automake has a script called "compile" (I don't know if this cccl
is related or not) which is automatically installed into packages using
Automake if they use AC_PROG_CC to find a C compiler.

Cheers,
  Nick

Re: Improve Autoconf MSVC support

[Nick Bowler]

Hi Antonin,

On 2024-06-03 12:05, Antonin Décimo wrote:
> Dear maintainers,
> 
> I've listed three little problems I've had using MSVC and Autoconf.
> They stem from MSVC not accepting the same parameters from the usual
> unix tools. I wonder if these could be fixed. I'm happy to help with
> testing.
> 
> Note that MSVC supports both `/param` and `-param` styles; the former
> being used in documentation, but I think we should prefer the latter
> for Unix compatibility (compilers might interpret the `/param` style
> as paths).

Yes, using the slash form of the options is fraught with peril (in
particular, MSYS looks for command line arguments that look like
UNIX-style absolute filenames and modifies them by prepending
drive letters).  Fortunately the hyphen form works fine.

> - `AC_SEARCH_LIBS`: the macro prepends `-llibrary` to `LIBS` to look
>   for a function in a library. MSVC doesn't recognize these arguments,
>   and expects `library.lib` at the end of its invocation.
>   Also applies to `{AC,AH}_CHECK_LIB`.
> 
> - Output file
> 
>   MSVC will stop supporting `/o`/`-o` to select its output file and is
>   already warning about it.
[...]

I guess you are not using Automake, because both of these problems
should be solved automatically by Automake.  Automake replaces $CC
with invocations through a wrapper script that knows how to translate
-l and -o options into MSVC equivalents (such as -Fo/-Fe).

If you don't want to use Automake I suggest at least using this
wrapper script in your project.

The combination of -c with -o is not even portable amongst POSIX
hosts (the POSIX-standard compiler commands leave the results of
this combination explicitly unspecified).

> - Version flag
> 
>   MSVC doesn't have a version flag but will report its version if
>   called directly.

I don't understand why this is important.

Cheers,
  Nick

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

[Nick Bowler]

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

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

If you cannot successfully regenerate configure from a source tarball,
it is probably missing some of the source code for the configure script,
which is a problem if it was supposed to be a free software package.

Cheers,
  Nick

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

[Nick Bowler]

On 2024-04-09 18:06, Sam James wrote:
> Nick poses that a specific combination of tools is what is tested and
> anything else invalidates it. But how does this work when building on
> a system that was never tested on, or with different flags, or a
> different toolchain?
>
> It's reasonable to say "look, if you do this, please both state it
> clearly and also do some investigation first to see if you can
> reproduce it with my macros", but I don't think it's a crime for
> someone to attempt it either.

To be clear, I don't mean to suggest that modifying a package by
replacing m4 sources with different versions and/or regenerating
configure with a different version of Autoconf is something that
should never be done by downstream distributors.  If doing this
solves some particular problem, then by all means do it, that's
an important part of what free software is all about.

What I have a problem with is the suggestion that distributors should
systematically throw away actually-tested configure scripts by just
discarding any m4 source files that appear to be copied from another
project (Gnulib, in this case), copying in new ones from a possibly
different version of that project, regenerating the configure script
using a possibly different version of Autoconf, and then expecting
that this process will produce high-quality results.

Cheers,
  Nick

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

[Nick Bowler]

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

If I distribute a release package, what I have 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.

This is fine, modifying a package and distributing modified versions
are freedoms 1 and 3, but if it breaks you keep both pieces.

The aclocal --install feature should be seen as a feature to help update
dependencies as part of the process of preparing a modified version, not
something that should ever be routinely performed by system integrators.

GNU/Linux distributions have a long history of buggy backports to the
autotools.  For a recent example, Gentoo shipped a broken libtool 2.4.6
which included a patch to make Gentoo installs go faster but if you
prepared a package with this broken libtool version, the resulting
package would not build on HP-UX, oops.

Cheers,
  Nick

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

[Nick Bowler]

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

Autoheader can't possibly know in advance what text some arbitrary
shell expansion might contain when the configure script is executed.
So, as documented[1], it only works when the first argument to
AC_DEFINE_UNQUOTED is a "literal" (essentially, something that
looks like it will be unchanged by shell quotation).

You can use AH_TEMPLATE[2] to instruct autoheader about any template
lines that it should include which are not determined automatically.

[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#autoheader-Invocation
[2] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#Autoheader-Macros

Hope that helps,
  Nick

Re: AC_TYPE_LONG_LONG_INT busted in current Autoconf

[Nick Bowler]

On 2024-01-16 23:22, Paul Eggert wrote:
> Thanks for reporting that bug. I installed the attached on Savannah; please 
> give it a try.

I applied the patch on top of the 2.72 release.  You definitely need to also 
remove the ;;
on the previous lines, every shell I try (new and old) now barfs on the case 
statement,
e.g.,

  % ./configure   
  [...]
  checking for unsigned long long int... ./configure[3221]: syntax error at 
line 3229 : `confdefs.h' unexpected

If I remove the ;; too it seems to be working.

Thanks,
  Nick

AC_TYPE_LONG_LONG_INT busted in current Autoconf

[Nick Bowler]

Hi,

In recent versions of Autoconf, AC_TYPE_LONG_LONG_INT (and
AC_TYPE_UNSIGNED_LONG_LONG_INT) wrongly indicate that (unsigned) long
long is supported on compilers which actually do not support it.

Looking at the implementation of AC_TYPE_LONG_LONG_INT, it contains:

  ac_cv_type_long_long_int=yes
  case $ac_prog_cc_stdc in
  no | c89) ;;
  *) [ run compiler probes ]
  esac

which looks like it is assuming "long long" is supported for
pre-standard and C89 compilers, only actually running checks
on compilers which support newer C standards; presumably this
is the opposite of what is intended.

The failure is easy to demonstrate with gcc:

  % cat >configure.ac <<'EOF
  AC_INIT([test], [0])
  AC_PROG_CC
  AC_TYPE_LONG_LONG_INT
  AC_OUTPUT
EOF
  
  % autoconf-2.72 --force
  % ./configure CC='gcc -Werror=long-long'
  [...]
  checking for gcc -Werror=long-long option to enable C11 features... 
unsupported
  checking for gcc -Werror=long-long option to enable C99 features... 
unsupported
  checking for gcc -Werror=long-long option to enable C89 features... none 
needed
  checking for unsigned long long int... yes
  checking for long long int... yes

The last apparently working version is autoconf-2.70, but that is
because this version of autoconf has a different bug which causes it to
believe C89 compilers support C99 (so the long long test is run in this
version).  The last actually working version is autoconf-2.69:

  % autoconf-2.69 --force
  % ./configure CC='gcc -Werror=long-long'
  [...]
  checking for gcc -Werror=long-long option to accept ISO C89... none needed
  checking for unsigned long long int... no
  checking for long long int... no

Cheers,
  Nick

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

[Nick Bowler]

On 2024-01-13 03:26, Румен Петров wrote:
> autoconf 2.72 is first release that prints warning:
> configure.ac:2: warning: file 'version.m4' included several times

The warning here is erroneous and happens now because Autoconf-2.72's
m4sugar.m4 (which is used under the hood basically everywhere) now
includes an expansion of m4_sinclude([version.m4]).

Autoconf implements this warning with a very simplisic check for whether
a file is actually included multiple times: it defines the m4_include
and m4_sinclude macros which record the argument any time they are used,
checking if either was ever called with that argument before.

Now, m4sugar does not _actually_ include your version.m4, because the
Autoconf build/installation process generates an m4 "frozen state" file
(m4sugar.m4f) where the file inclusion is already done using version.m4
from Autoconf's source code, and this is what actually gets used when
you run autoconf.  However, the frozen state *does* include the record
that m4_sinclude was expanded previously with the version.m4 argument.

Probably we could fix this problem by changing m4sugar.m4 to not use
the m4_sinclude.  It could use m4_builtin([sinclude], [version.m4])
instead which would then not expose the record of internal inclusions
to the user like this.

To work around the warning in autoconf-2.72, you can change the spelling
of version.m4 to something functionally equivalent, for example:

  m4_include([./version.m4])

You can also just go in and delete the indication that Autoconf uses
to produce this warning, for example:

  m4_builtin([undefine], [m4_include(version.m4)])

Incidentally, while not relevant to your example, Autoconf 2.72 also
installs its own version.m4 file to the global m4 include search path,
so if you were previously using M4PATH or autoconf's -I option to locate
a file with this name then actually m4_include([version.m4]) will pick
up the one shipped with Autoconf instead of what probably anyone would
actually want to happen in this scenario.

Cheers,
  Nick

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

[Nick Bowler]

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

I tested several modern, current operating systems, including:
  OpenBSD 7, NetBSD 9, FreeBSD 13, Alpine Linux 3.15
I also tested several not-so-modern systems, including:
  DJGPP, HP-UX 11, Solaris 8.

On every single one of these systems, the /usr/bin/printf (or equivalent)
does not generally diagnose errors that occur when writing to standard
output, and an exit status of 0 is returned.

Further notes:

The shell on FreeBSD has a printf builtin which does diagnose such
errors and does exit with a nonzero status.

The shell on Alpine has a printf builtin which does not diagnose such
errors but does exit with a nonzero status.

The shell on NetBSD has a printf builtin which does not diagnose such
errors and exits with a 0 status.

The DJGPP bash shell has a printf builtin which does not diagnose such
errors and exits with a 0 status.

The version of bash that comes with Solaris 8 has a printf builtin which
does not diagnose such errors and exits with a 0 status.

The other systems tested do not have printf builtins in their shells, so
plain "printf" invokes "simply broken" /usr/bin/printf.

So sure, we can call it a "bug" and we can call these systems "simply
broken" but the reality is that these systems exist and portability means
dealing with this behaviour even if it is not what we wish they would do
or what some piece of paper says they should do.

There are probably a lot more systems with a "simply broken" printf,
as the printf utilities in SVr4 and 4.4BSD will also behave like this...

Cheers,
  Nick

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

[Nick Bowler]

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

I think you might want to double check your test setup.  This error
message is exactly what you'd get if you are running printf from a
recent release of GNU coreutils, rather than the /usr/bin/printf
that comes with Solaris.

I don't have a Solaris 10 box handy for testing right now but neither
Solaris 8 /usr/bin/printf nor heirloom-tools printf (which is ported
from OpenSolaris, contemporaneous with Solaris 10) print this error
message, and neither exit with status 1.

Cheers,
  Nick

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

[Nick Bowler]

On 2023-12-21 13:48, Zack Weinberg wrote:
> and an unsuccessful exit status.  I would guess that on your machine
> the printf built-in and/or standalone printf executable are not
> reporting write errors.

I think it is not reasonable to expect any utility to report any kind
of error on writes to standard output.  This is not normal behaviour
for C programs and, in the case of printf utilities which are not shell
builtins, such behaviour is likely unique to GNU.

Without /dev/full it is difficult to portably trigger write errors,
but NetBSD 9 has /dev/full and its /usr/bin/printf also does not
report such errors.

You can more reliably get errors by redirecting to a pipe and closing
the read end. since in this case the SIGPIPE will not go unnoticed,
(although an ignored SIGPIPE is inherited from the parent process which
may affect the results).  This can be tricky to setup in a shell script
though.

Cheers,
  Nick

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

[Nick Bowler]

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

This fact is also explicitly mentioned in the Autoconf documentation[1]:

  In code portable to both traditional and modern Awk, FS must be a
  string containing just one ordinary character, and similarly for
  the field-separator argument to split.

The heirloom-tools package[2] includes a traditional awk with this
particular limitation.  This is a free software implementation (ported
from OpenSolaris) that can be installed on a modern GNU/Linux system.
It should be very similar to Solaris 10 /bin/awk:

  % echo abcdefg | heirloom-tools/5bin/awk '{ split($1, a, /c?e/); print a[2]; 
}'
  awk: syntax error near line 1

  % echo abcdefg | heirloom-tools/5bin/awk '{ split($1, a, "c?e"); print a[2]; 
}'
  defg

Even with AC_PROG_AWK, on ULTRIX it selects "nawk" which still does not
work with a regexp argument to split, but it does work if the argument
is a string which can be interpreted as a regexp:

  ultrix% echo abcdefg | nawk '{ split($1, a, /c?e/); print a[2]; }'
  [no output]

  ultrix% echo abcdefg | nawk '{ split($1, a, "c?e"); print a[2]; }'
  fg

[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#Limitations-of-Usual-Tools
[2] https://heirloom.sourceforge.net/tools.html

Cheers,
  Nick

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

[Nick Bowler]

On 2023-12-08 09:25, Zack Weinberg wrote:
> Thinking about this one some more, I see two ways to make confdefs.h
> idempotent:
> 
> 1. A conventional "multiple inclusion guard", wrapping the body of the file in
> #ifndef ... #endif.  This will work on all compilers and regardless of whether
> confdefs.h is included or concatenated with the test program, but requires us
> to change AC_DEFINE and friends to do something like
> 
> 
> #define MACRO 1
> 
> 
> The thing I'm worried about with this one is if there's third party macros out
> there somewhere that bypass AC_DEFINE.  The sed construct up there should be
> portable.

I think your sed construct must have been eaten somewhere along the line.  
Without
being able to see the suggestion, I imagine that using sed to rewrite confdefs.h
every time is going to incur quadratic runtime complexity while simply appending
new definitions to an existing file normally does not.

>From what I understand of this issue, I don't think we should change anything
in Autoconf because there does not seem to be any real advantage to fixing this.

  - Excluding the NEWS item which references this one report, the Autoconf 
documentation does not mention confdefs.h even once.  This issue can
only affect packages relying on undocumented Autoconf internals.  It
does not affect normal usage of AC_LANG_SOURCE and friends.

  - We have exactly one report of problems (apr), and this package has been
updated to use AC_LANG_PROGRAM since this was reported.

  - The consequence of this issue is just a compiler warning from a few
versions of one compiler (admittedly an important one).

The bogus warning should just be fixed in gcc.

> 2. Alternatively, use #pragma once and change AC_LANG_CONFTEST(C) to #include
> confdefs.h rather than prepending its contents to the test program.  This
> would keep macros that bypass AC_DEFINE working, but would break with
> compilers that make #pragma once do something wacky (it should be no worse
> than the status quo with compilers that merely _ignore_ #pragma once). I also
> wonder if there's a concrete reason why AC_LANG_CONFTEST(C) _shouldn't_
> #include confdefs.h.

Using nonstandard pragmas seems even worse to me, and just moves the problem
elsewhere (many compilers will warn by default if they encounter "#pragma once"
by default, including older versions of gcc!).

If you really want to work around this gcc bug then it is probably sufficient
to just install special cases in the internal Autoconf macros that generate
these definitions of the problematic macros, for example (untested):

  #ifndef AC_DEFINED__STDC_WANT_IEC_60559_ATTRIBS_EXT__
  #define AC_DEFINED__STDC_WANT_IEC_60559_ATTRIBS_EXT__
  #define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
  #endif

Then this could still be inserted to confdefs.h by appending and does not
rely on any nonstandard pragmas.

Cheers,
  Nick

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

[Nick Bowler]

On 2023-12-07 21:28, Zack Weinberg wrote:

Follow-up Comment #1, sr#110846 (group autoconf):

We regret the delay in responding to this bug report.

I believe this is the same as #110348.  The proposal there would make it so
you could force a configure script into cross-compilation mode, even when the
build and host triples are the same and the cross-compiled executables can run
on the build system, by specifying --host and *not* --build.  Would that work
for you?  (Please reply in #110348, I'm going to close this report.)

This will not happen for 2.72 but hopefully will for the release after that.


You can already force cross-compilation mode today by running

  ./configure cross_compiling=yes

I think it would be better to simply document this more clearly. 
Changing the behaviour of --host (without --build) to force cross 
compilation mode seems ill-advised.  As I recall, this was tried before 
some years back and there were complaints by people cross-building with 
mingw on GNU/Linux build systems, who actually wanted the runtime tests 
to be done.


I think the current wording in the manual (which de-emphasized the 
recommendation to always specify --build and --host together) came as a 
result of those complaints, and it explicitly mentions the mingw use case.


Cheers,
  Nick

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

[Nick Bowler]

On 2023-11-29 14:29, Zack Weinberg wrote:
> On Wed, Nov 29, 2023, at 9:32 AM, Dennis Clarke via Bug reports for autoconf 
> wrote:
[...]
>> --- ./at_config_vars-state-env-expected 2023-11-29 09:14:04.189405540 -0500
>> +++ ./at_config_vars-state-env.after2023-11-29 09:14:04.189405540 -0500
>> @@ -47,7 +47,7 @@
>>   PWD=/root/autoconf-2.71/tests/testsuite.dir/254
>>   SHELL=/bin/bash
>>   SHELLOPTS=braceexpand:hashall:interactive-comments:posix
>> -SHLVL=2
>> +SHLVL=3
>>   TAR_OPTIONS='--owner=0 --group=0 --numeric-owner'
>>   TERM=xterm-256color
>>   UID=0
> 
> Changes in the value of SHLVL are supposed to be ignored.

No current Autoconf release includes the fix[1] to ignore SHLVL in the test 
suite.

Current versions of devuan ship bash-5.2 which is probably why this failure is 
happening.
Devuan, like debian, ships a crippled dash (with broken $LINENO) as /bin/sh so 
Autoconf's
test suite by default re-execs itself with /bin/bash and then hits all these 
problems.

This might be a sufficient workaround:

  % make check run_testsuite='CONFIG_SHELL=/bin/sh /bin/sh tests/testsuite -C 
tests MAKE=$(MAKE)'

[1] 
https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=412166e185c00d6eacbe67dfcb0326f622ec4020

Cheers,
  Nick

Re: m4_ax_check_typedef.m4 fixes

[Nick Bowler]

Hi,

On 2023-11-11 04:34, stsp wrote:

Hi, I've found the m4_ax_check_typedef.m4 script here:
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_typedef.m4


This is the Autoconf list, which despite the confusingly similar name is 
unrelated to the "Autoconf Archive" project.



It appears to be very buggy:


Yes, we unfortunately we get a lot of reports of problems in the 
Autoconf Archive sent to the Autoconf lists.



Attached is the fixed version of a script.

According to

  https://www.gnu.org/software/autoconf-archive/How-to-contribute.html

The preferred way to submit patches to the autoconf archive is via the 
patch tracker[1] on Savannah.  You could also try the mailing list[2] at 
autoconf-archive-maintain...@gnu.org (but this is not mentioned on the 
how to contribute page).


[1] http://savannah.gnu.org/patch/?func=additem=autoconf-archive
[2] https://lists.gnu.org/mailman/listinfo/autoconf-archive-maintainers

Hope that helps,
  Nick

Re: AC_PROVIDE{_IFELSE} not documented?

[Nick Bowler]

On 18/06/2023, Karl Berry  wrote:
> Maybe I'm going blind, but it seems that AC_PROVIDE and
> AC_PROVIDE_IFELSE are not documented in the Autoconf manual. AC_PROVIDE
> is mentioned but not described.  AC_PROVIDE_IFELSE is not mentioned.

When I reported this many years ago, the response[1] at the time was
"the macros are stable and intended to be usable; we're just missing
the documentation patch."

But neither I nor anyone else stepped up to actually write it.

[1] https://lists.gnu.org/archive/html/autoconf/2012-12/msg0.html

Cheers,
  Nick

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

[Nick Bowler]

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

By setting --host and --build to the same value, this explicitly forces
non-cross-compilation mode in configure.

If you specify --host without also specifying --build, then configure will
run the auto-detection which I expect will work properly for you.

Probably the "vendor" field of the host triplet should have been set to
something different for these different systems, but I digress...

> And there seems to be no way to force it if we know that we are cross
> compiling.

Nevertheless, you can always force cross compilation mode by explicitly
setting cross_compiling=yes, for example:

  % ./configure cross_compiling=yes

Hope that helps,
  Nick

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

[Nick Bowler]

On 2022-07-27, anonymous  wrote:
> Follow-up Comment #2, sr #110687 (project autoconf):
>
>> It appears to me that this is an issue with cross compilation and strict
> conformance mode (-std=c11), not with -flto.  Could you please report what
> happens, using the same cross-compilation toolchain, if you run the same
> configure command but using CFLAGS="-std=c11" LDFLAGS="" ?
>
> In that case (only -std=c11) everything works as expected.
>
> checking for unistd.h... yes
> checking whether byte ordering is bigendian... no
> configure: creating ./config.status
> config.status: creating issue618config.h
>
>
> The issue only occurs when using -flto.

This is not all that surprising.

Since Autoconf cannot run programs when cross compiling, Autoconf has
to use some other method.  One thing it tries is to use various
extensions found in the system header files, however this is obviously
not working with glibc when -std=c11 is used to disable extensions.

The other method inspects the code in compiled object files.  However,
-flto prevents generation of object files which are usable for this
purpose (as all the backend work is deferred to link time).  If you
use -ffat-lto-objects as well, the test should work again.

To fix this in Autoconf, probably just #defining _GNU_SOURCE or similar
directly in the test programs used by AC_C_BIGENDIAN can solve the
problem with the library header test.

To fix this in your package, I suggest just providing an action-if-unknown
argument to AC_C_BIGENDIAN, and adjust your package to work in that case
(usually this can be done easily with a runtime test).

In general, I don't recommend using strict standards-conformance modes
ever unless you are implementing standards-conformance test suites.
Such options typically cause more portability problems than they solve.

Cheers,
  Nick

Re: Wrong order of preprocessor and compiler flags

[Nick Bowler]

On 2022-03-24, Zack Weinberg  wrote:
> On Thu, Mar 24, 2022, at 11:13 AM, Nick Bowler wrote:
>> However, GNU coding standards state that CFLAGS should be the last
>> item on compilation commands, so it would appear that this is a case
>> where traditional "make" behaviour contrasts with GNU standards (which
>> Automake is following).
>
> Huh.  Is there a rationale given in the coding standard?  If not, do you
> have any idea who might remember the rationale?

The GNU standards just say this[1]:

  "Put CFLAGS last in the compilation command, after other variables
   containing compiler options, so the user can use CFLAGS to override
   the others."

When it comes to C(PP)FLAGS the concept of "overriding" options is a
bit hairy -- many C compiler options do not have direct methods to undo
their effects -- but whatever.

[1] https://www.gnu.org/prep/standards/standards.html#Command-Variables

Re: Wrong order of preprocessor and compiler flags

[Nick Bowler]

On 2022-03-23, Zack Weinberg  wrote:
> On Wed, Mar 23, 2022, at 11:31 AM, Evgeny Grin wrote:
>> I've found that everywhere in autoconf scripts flags are used like:
>> $CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >_MESSAGE_LOG_FD
>> while automake and libtool use flags in the other order:
>> $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS)
>> $(AM_CFLAGS) $(CFLAGS)
>
> I agree that this should be made consistent, but before we change
> anything, we need to check what the rules *built into GNU and BSD
> Make* do with CFLAGS and CPPFLAGS (and also CXXFLAGS, OBJCFLAGS, etc)
> because those are much much harder to get changed than anything in
> Automake or Autoconf, so we should aim to harmonize everything with
> them.

Practically all make implementations use the $(CFLAGS) $(CPPFLAGS)
ordering in their builtin .c.o inference rules.

However, GNU coding standards state that CFLAGS should be the last
item on compilation commands, so it would appear that this is a case
where traditional "make" behaviour contrasts with GNU standards (which
Automake is following).

Cheers,
  Nick

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

[Nick Bowler]

On 2021-07-27, Eric Siegerman  wrote:
> Follow-up Comment #4, sr #110212 (project autoconf):
>
> 0 Edit _configure.ac_: In the _AC_INIT()_ call, change the first argument
> to
> the name you want to use for the subdirectory
> 0 Run _autoconf_ (perhaps indirectly, if the package provides an
> _autogen.sh_
> script or the like)
> 0 Run _configure_ with _--program-prefix_, _--program-suffix_, and/or
> _--program-transform-name_, as desired
> 0 Once the build is finished, do a test install into a scratch location
> using
> _DESTDIR=/where/ever_, and look it over to make sure all the pathnames that
> needed to be changed, were in fact changed.

Instead of all this hackery you can just set pkgdatadir when you build the
program, surely that's easier.  For example:

  % make clean
  % make pkgdatadir=/wherever/you/want install

This is expected to work with all build systems that follow the GNU
coding standards.

Cheers,
  Nick

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

[Nick Bowler]

Hi Dima,

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

AC_WARNING has not been removed.

The only change is now you get a warning (with -Wobsolete) and autoupdate
will suggest to change it.  This macro has been deprecated[1] since
Autoconf 2.62 (ca. 2008).

Is there some problem with the replacement suggested by autoupdate?

> Also, there are few weird replacements for aliases generated, e.g.
> -AU_ALIAS([CHECK_SSL], [AX_CHECK_OPENSSL])
> +AU_ALIAS([AX_CHECK_OPENSSL], [AX_CHECK_OPENSSL])
> in ax_check_openssl.m4
> https://www.gnu.org/software/autoconf-archive/ax_check_openssl.html

This is a known problem with autoupdate[2].  It doesn't actually
understand m4 syntax so it often runs into problems similar this one.

As a workaround, you can tweak the quoting to avoid such counterproductive
suggestions in the future; for example:

  AU_ALIAS([CHECK_][OPENSSL], [AX_CHECK_OPENSSL])

[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.62/autoconf.html#index-AC_005fWARNING-1271
[2] https://lists.gnu.org/archive/html/bug-autoconf/2021-01/msg00023.html

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

[Nick Bowler]

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

These sort of issues are typically caused by underquoting, probably
within the definition of CMU_HAVE_OPENSSL and/or CMU_FIND_LIB_SUBDIR.

Due to technical limitations of m4, AC_REQUIRE does not work properly
when it is expanded during argument collection.  This is not usually
a problem when arguments are quoted properly: one of the reasons
why proper quoting is so important.

> IMO there's something wrong with calling AC_TRY_RUN in AC_CACHE_VAL.

If you could share the code in question, I can give more specific
comments.  But my totally wild guess is that the second argument to
AC_CACHE_VAL is not quoted.

Cheers,
  Nick

Re: autoupdate: AU_ALIAS shouldn't affect itself

[Nick Bowler]

On 2021-01-26, egall--- via Bug reports for autoconf
 wrote:
> Say I have an M4 macro file with an AU_ALIAS usage in it like this:
>
> AU_ALIAS([BNV_HAVE_QT], [AX_HAVE_QT])
>
> If I run autoupdate on this file, that will become:
>
> AU_ALIAS([AX_HAVE_QT], [AX_HAVE_QT])
>
> This seems pointless, as now the AU_ALIAS won't do what it was originally
> meant to do anymore. Perhaps autoupdate could be updated to stop making
> this change.

It does seem counterproductive.  Unfortunately autoupdate doesn't actually
understand m4 syntax so it often runs into problems similar this one.  I'm
sure it could be improved to better handle this specific case, though.

But for the same reason, you should be able to work around the problem
just by quoting differently, for example:

  AU_ALIAS([BNV_][HAVE_QT], [AX_HAVE_QT])

Cheers,
  Nick

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

[Nick Bowler]

On 2021-01-16, Michael Labbé  wrote:
> realpath() is failing to compile for me on MacOS 11.1 on an Apple M1 Mac.  I
> encountered this when building GNU Global Tags from the most recent source
> archive at global-6.6.5.tar.gz
> .
>
> This is due to an error because realpath cannot be found. The fix is to
> modify configure to include stdlib.h.
>
> Line 14291 of configure on global-6.6.5:
>
> main(){ (void)realpath("/./tmp", (void *)0); return 0; }
> Insert one line before that:
>
> #include
> main(){ (void)realpath("/./tmp", (void *)0); return 0; }
> configure now succeeds.
>
> The Brew folks and the Global Tags folks told me to report the bug here.

This code does not come from Autoconf, so I'm unsure why you were asked
to report it here.

The code comes from the global package itself (in their configure.ac file):

  AC_RUN_IFELSE([AC_LANG_SOURCE([[
  main(){ (void)realpath("/./tmp", (void *)0); return 0; }
  ]])],[ac_cv_posix1_2008_realpath=yes],
  [ac_cv_posix1_2008_realpath=no])

This is the where the problem needs to be corrected.

Cheers,
  Nick

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

[Nick Bowler]

On 2020-10-22, Zack Weinberg  wrote:
> I acknowledge that requiring double-quotation of AC_INIT arguments
> when they contain characters significant to M4 _should_ work; however,
> it did not work in my tests (which were not exactly the same as the
> above; see the "AC_INIT with unusual version strings" test case in
> tests/base.m4, on the branch).  Also, it increases the compat hit
> we're taking, since e.g.
>
> AC_INIT(GNU MP, GMP_VERSION, [gmp-b...@gmplib.org, see
> https://gmplib.org/manual/Reporting-Bugs.html], gmp)
>
> which also worked with 2.69, will now be considered invalid,

If this works in 2.69 I don't see why this snippet would be rendered
invalid if AC_INIT did not over/underquote, because ...

> Would you care to propose a complete patch to be applied on top of
> zack/ac-init-quoting?  In addition to "reverting hunks" you would need
> to make sure that AC_PACKAGE_* are always treated consistently within
> lib/autoconf/*.m4, fix the testsuite by adding double quotation to AC_INIT
> arguments where necessary, and document in both doc/autoconf.texi and NEWS
> the changed requirements for AC_INIT arguments.

... I am not suggesting we change any behaviour to AC_INIT arguments wrt.
quoting, as compared to Autoconf 2.69.  As far as I know this version
dutifully follows typical m4 quoting conventions, I am not aware of
any specific under/overquotation in existing releases.

This underquotation (2.69c) and overquotation (zack/ac-init-quoting
branch) is a behaviour change compared to 2.69.  I am proposing we NOT
change the amount of quoting, but rather we should stick with normal m4
conventions, which would avoid all the AC_INIT-related regressions I've
seen reported so far to this list.

Anyway, I should have some time on the weekend, I'll see what I can do
about proposing a proper patch :)

Cheers,
  Nick

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

[Nick Bowler]

On 22/10/2020, Zack Weinberg  wrote:
> On Thu, Oct 22, 2020 at 11:53 AM Nick Bowler  wrote:
>> On 2020-10-22, Zack Weinberg  wrote:
>> > On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert 
>> > wrote:
>> >>
>> >> On 10/21/20 6:15 AM, Zack Weinberg wrote:
>> >> > We*could*  add a special case in AC_INIT where, if any of the third,
>> >> > fourth, or fifth arguments contain the literal strings
>> >> > `AC_PACKAGE_NAME` or `AC_PACKAGE_VERSION`, those are replaced with
>> >> > the
>> >> > values of the first and second argument, respectively.  This would
>> >> > keep the GHC code working as-is.  I'm not sure whether that's a good
>> >> > idea; cc:ing Paul and Eric for their thoughts.
>> >>
>> >> I'm not following all the details here
>> >
>> > The concrete problem is that, without the hack I described, we cannot
>> > support both
>> >
>> > AC_INIT([foo], [1.0], [foo-...@foo.org], [foo-AC_PACKAGE_VERSION])
>> >
>> > and
>> >
>> > AC_INIT([bar], [1.0], [foo-bug@[192.0.2.1]])
>>
>> I think this is missing the point.  The m4 way is that such an
>> email address should simply be double quoted to avoid the unwanted
>> m4 expansion, for example:
>>
>>   AC_INIT([bar], [1.0], [[foo-bug@[192.0.2.1]]])
>
> I tried that and it doesn't work.  No amount of extra quotation (ok, I
> only went up to four levels before I gave up) will prevent the square
> brackets from being lost, if I don't have autoconf use m4_defn to set
> the value of the shell variable PACKAGE_BUGREPORT.

It works perfectly fine for me with Autoconf-2.69...

  % cat >configure.ac <<'EOF'
AC_INIT([bar], [1.0], [[foo-bug@[192.0.2.1]]])

AS_ECHO(["AC_PACKAGE_BUGREPORT"])
AS_ECHO(["$PACKAGE_BUGREPORT"])

AC_OUTPUT
EOF

  % autoconf-2.69
  % ./configure
  2.69
  foo-bug@[192.0.2.1]
  foo-bug@[192.0.2.1]
  configure: creating ./config.status

And it also works as expected with the zack/ac-init-quoting branch if I
simply revert the patch hunks identified earlier in this thread:

  % autoconf-zack-patched
  % ./configure
  2.69c.10-6487-dirty
  foo-bug@[192.0.2.1]
  foo-bug@[192.0.2.1]
  configure: creating ./config.status

If the hunks are not reverted, quotation problems are readily apparent:

  % autoconf-zack-unpatched
  2.69c.10-6487
  foo-bug@[192.0.2.1]
  [foo-bug@[192.0.2.1]]
  configure: creating ./config.status

(those patch hunks are not the only instances of overquotation added by the
patch, I see that the patch also overquotes the bugreport address in the
configure --help text)

Cheers,
  Nick

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

[Nick Bowler]

On 2020-10-22, Zack Weinberg  wrote:
> On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert  wrote:
>>
>> On 10/21/20 6:15 AM, Zack Weinberg wrote:
>> > We*could*  add a special case in AC_INIT where, if any of the third,
>> > fourth, or fifth arguments contain the literal strings
>> > `AC_PACKAGE_NAME` or `AC_PACKAGE_VERSION`, those are replaced with the
>> > values of the first and second argument, respectively.  This would
>> > keep the GHC code working as-is.  I'm not sure whether that's a good
>> > idea; cc:ing Paul and Eric for their thoughts.
>>
>> I'm not following all the details here
>
> The concrete problem is that, without the hack I described, we cannot
> support both
>
> AC_INIT([foo], [1.0], [foo-...@foo.org], [foo-AC_PACKAGE_VERSION])
>
> and
>
> AC_INIT([bar], [1.0], [foo-bug@[192.0.2.1]])

I think this is missing the point.  The m4 way is that such an
email address should simply be double quoted to avoid the unwanted
m4 expansion, for example:

  AC_INIT([bar], [1.0], [[foo-bug@[192.0.2.1]]])

This works already, as expected, in existing versions of Autoconf.

But if your package actually used such an email address today, it will
be broken by the patch due to the overquotation in AC_INIT.  To avoid
regressions like the one reported, and to be consistent with how most
macros are expected to function, we should simply not overquote in
the definition of AC_INIT.

Cheers,
  Nick

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

[Nick Bowler]

On 2020-10-21, Zack Weinberg  wrote:
> On Tue, Oct 20, 2020 at 4:57 PM Nick Bowler  wrote:
>> Note: the change you report is introduced by Zack's fix for related
>> AC_INIT quoting regressions.  This patch is not included in 2.69c (or
>> even on git master), but does seem to be applied by the Gentoo package.
>
> Yeah, this is a "can't have it both ways" kind of thing.  We can
> reliably round-trip "unusual" characters (like the ones that appear
> all the time in URLs and email addresses) through AC_INIT's arguments,
> or we can expand macros in those arguments even when they're quoted on
> input; I don't think there's any way to do both.

M4 macros (including AC_INIT) should normally follow the m4 quoting rule
of thumb, which is that the amount of quotation should exactly equal the
depth of macro expansion.  Remembering that extra quotation added by
macros such as m4_defn and m4_dquote count for this.

Previously AC_INIT had not enough quotation, i.e., less levels of
quotation than expansion, which lead to unexpected behaviour.

Now, with the patch, AC_INIT is adding more levels of quotation than
expansion, leading to different unexpected behaviour.

M4 macros are happiest when the level of quotation is just right :)

> This only works by accident in 2.69, incidentally.  AC_PACKAGE_VERSION
> is defined *after* AC_PACKAGE_TARNAME (see _AC_INIT_PACKAGE, lines
> 235-261 of $prefix/share/autoconf/general.m4) so both old and new
> autoconf set AC_PACKAGE_TARNAME to the literal string
> "ghc-AC_PACKAGE_VERSION".

While I agree it's probably a bit "naughty" to use AC_PACKAGE_VERSION
in the argument to AC_INIT it is a red herring.  Use of any macro would
have the exact same problem.

I'd expect double-quoted arguments to AC_INIT to be similarly broken
with this patch while previously they would work as expected.

> The value undergoes an extra round of expansion when it's used to set
> the shell variable PACKAGE_TARNAME (lines 416-428 of the same file).
> This extra round of expansion is undesirable in general.

I don't think I agree, when macro expansion is undesired the normal way
is to double-quote the arguments, which properly suppresses expansion
when macro definitions follow quoting the rule of thumb.

Cheers,
  Nick

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

[Nick Bowler]

Hi,

On 2020-10-20, Sergei Trofimovich  wrote:
> Initial bug is reported as autoconf failure on ghc-8.8.4:
> https://bugs.gentoo.org/750191
> There autconf 2.69 works, 2.69c does not.

Note: the change you report is introduced by Zack's fix for related
AC_INIT quoting regressions.  This patch is not included in 2.69c (or
even on git master), but does seem to be applied by the Gentoo package.

The 2.69c release version seems to handle the example fine.

> Here is the minimal example:
>
> OK:
>
>   $ cat configure.ac
>   AC_INIT([The Glorious Glasgow Haskell Compilation System], [9.1.0],
> [glasgow-haskell-b...@haskell.org], [ghc-AC_PACKAGE_VERSION])
>
>   echo "$PACKAGE_VERSION"
>
>   AC_OUTPUT
>   $ autoconf-2.69
>   $ ./configure
>   9.1.0
>   configure: creating ./config.status
>
> BAD:
>
>   $ autoconf-2.70_beta2
>   configure.ac:1: error: possibly undefined macro: AC_PACKAGE_VERSION
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.

Yes I think now Zack's underquotation fixes have added the opposite
problem.  There is now too much quotation so the tarname (and other
arguments) are not fully expanded when used.

At least these changes should probably be simply dropped from the patch
or at least they perhaps need more consideration...

@@ -436,18 +427,12 @@ AC_SUBST([SHELL])dnl
 AC_SUBST([PATH_SEPARATOR])dnl

 # Identity of this package.
-AC_SUBST([PACKAGE_NAME],
-[m4_ifdef([AC_PACKAGE_NAME],  ['AC_PACKAGE_NAME'])])dnl
-AC_SUBST([PACKAGE_TARNAME],
-[m4_ifdef([AC_PACKAGE_TARNAME],   ['AC_PACKAGE_TARNAME'])])dnl
-AC_SUBST([PACKAGE_VERSION],
-[m4_ifdef([AC_PACKAGE_VERSION],   ['AC_PACKAGE_VERSION'])])dnl
-AC_SUBST([PACKAGE_STRING],
-[m4_ifdef([AC_PACKAGE_STRING],['AC_PACKAGE_STRING'])])dnl
-AC_SUBST([PACKAGE_BUGREPORT],
-[m4_ifdef([AC_PACKAGE_BUGREPORT], ['AC_PACKAGE_BUGREPORT'])])dnl
-AC_SUBST([PACKAGE_URL],
-[m4_ifdef([AC_PACKAGE_URL],   ['AC_PACKAGE_URL'])])dnl
+AC_SUBST([PACKAGE_NAME],  ['m4_defn([AC_PACKAGE_NAME])'])dnl
+AC_SUBST([PACKAGE_TARNAME],   ['m4_defn([AC_PACKAGE_TARNAME])'])dnl
+AC_SUBST([PACKAGE_VERSION],   ['m4_defn([AC_PACKAGE_VERSION])'])dnl
+AC_SUBST([PACKAGE_STRING],['m4_defn([AC_PACKAGE_STRING])'])dnl
+AC_SUBST([PACKAGE_BUGREPORT], ['m4_defn([AC_PACKAGE_BUGREPORT])'])dnl
+AC_SUBST([PACKAGE_URL],   ['m4_defn([AC_PACKAGE_URL])'])dnl

 m4_divert_pop([DEFAULTS])dnl
 m4_wrap_lifo([m4_divert_text([DEFAULTS],
@@ -1099,9 +1084,8 @@ Fine tuning of the installation directories:
   --infodir=DIR   info documentation [DATAROOTDIR/info]
   --localedir=DIR locale-dependent data [DATAROOTDIR/locale]
   --mandir=DIRman documentation [DATAROOTDIR/man]
-]AS_HELP_STRING([--docdir=DIR],
-  [documentation root ]@<:@DATAROOTDIR/doc/m4_ifset([AC_PACKAGE_TARNAME],
-[AC_PACKAGE_TARNAME], [PACKAGE])@:>@)[
+  --docdir=DIRdocumentation root @<:@DATAROOTDIR/doc/]dnl
+m4_default_quoted(m4_defn([AC_PACKAGE_TARNAME]), [PACKAGE])[@:>@
   --htmldir=DIR   html documentation [DOCDIR]
   --dvidir=DIRdvi documentation [DOCDIR]
   --pdfdir=DIRpdf documentation [DOCDIR]

If you drop those two hunks from Zack's patch the example should work again.

Cheers,
  Nick

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

[Nick Bowler]

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

Today at least, Gentoo certainly does not install a "glibtoolize" nor
does it install a patched autoreconf that looks for this name.

I don't recall such a thing ever being the case but of course I could be
misremembering.  But a quick search of the historical repository turns
up no obvious evidence of such patches.

Cheers,
  Nick

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

[Nick Bowler]

On 2020-07-27, Zack Weinberg  wrote:
> URL:
>   
>
>  Summary: Make it possible to request a specific
> (non-latest)
> version of a language standard
>  Project: Autoconf
> Submitted by: zackw
> Submitted on: Mon 27 Jul 2020 06:31:37 PM UTC
> Category: None
> Priority: 5 - Normal
> Severity: 1 - Wish
>   Status: None
>  Privacy: Public
>  Assigned to: None
> Originator Email:
>  Open/Closed: Open
>  Discussion Lock: Any
> Operating System: None
>
> ___
>
> Details:
>
> Feedback on the 2.69b beta indicates that users find the new behavior of
> AC_PROG_CC and AC_PROG_CXX, automatically selecting the latest supported
> language standard, problematic.  Quoting
> https://lists.gnu.org/archive/html/autoconf/2020-07/msg00010.html :
>
>> One issue we [PostgreSQL] would like to point out is that
>> the new scheme of automatically checking for the latest
>> version of the C and C++ standards (deprecating AC_PROG_CC_C99
>> etc.) is problematic...
>>
>> [W]e have set C99 as the project standard. So checking for
>> C11 is (a) useless, and (b) bad because we don't want
>> developers to accidentally make use of C11 features and have
>> the compiler accept them silently.

I have no comments on the C++ side of things but on the C side this
request doesn't make too much sense.

As a portability tool, the goal of Autoconf and configure scripts is
to find a compiler that can successfully compile the application.

Aside from the removal of gets from the standard library (which most
C11 compilers still implement anyway) and that some language features
which were mandatory in C99 are now optional (which again, most C11
compilers implement anyway), C11 is essentially completely backwards
compatible with C99 so such a compiler should be perfectly fine for
building a C99 codebase.

AC_PROG_CC_C99 has never guaranteed that a C99 compiler will be selected,
it is "best effort" only and has always accepted C11 compilers provided
they support VLAs.  GCC has defaulted to C11 mode for the better part
of a decade now (since version 5) and AC_PROC_CC_C99 will not add any
options.

All compilers I'm aware of that support both C99 and C11 modes will
silently accept most if not all C11 features even when C99 mode is
selected by the user.  So having Autoconf select a C99 mode is probably
not going to do anything to help projects avoid modern language
features.  For the same reason it could be difficult to write a feature
test program which usefully determines that the compiler is in C99 mode
(probably the best you can do is test for specific values of the
__STDC_VERSION__ macro which is really not the Autoconf way).

If you don't want specific language constructs to be used in your
codebase the proper way to do this is with linting tools or warning
flags during development, not with portability tools like Autoconf.

For example with GCC if you want to reject new C11 syntax you can
build with the -Werror=c99-c11-compat option.  (You could even use
Autoconf to write a configure test that will automatically add this
option to CFLAGS if it is supported by the compiler.

Cheers,
  Nick

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

[Nick Bowler]

On 2020-07-16, Ross Burton  wrote:
[...]]
> libSDL2 fails to configure with autoconf 2.70 but works with 2.69:
>
> | checking for size_t... yes
> | checking for M_PI in math.h... ../SDL2-2.0.12/configure: line 13202: CPP:
> command not found
> | checking how to run the C preprocessor... gcc  -E
> | ../SDL2-2.0.12/configure: line 13328: ac_fn_c_try_cpp: command not found
> | ../SDL2-2.0.12/configure: line 13328: ac_fn_c_try_cpp: command not found
> | configure: error: in
> `/home/pokybuild/yocto-worker/qemux86-64/build/build/tmp/work/x86_64-linux/libsdl2-native/2.0.12-r0/build':
> | configure: error: C preprocessor "gcc  -E" fails sanity check
> | See `config.log' for more details
> | WARNING: exit code 1 from a shell command.
>
> The configure.ac is just a very badly named macro:
>
> AC_CHECK_DEFINE(M_PI, math.h)
>
> Which is implemented here:
>
> https://github.com/spurious/SDL-mirror/blob/master/acinclude/ac_check_define.m4
>
> This uses AC_EGREP_CPP but it doesn't appear to explicitly look for a cpp.
> My workaround is to explicltly call AC_PROG_CPP earlier: should AC_EGREP_CPP
> be doing this, or should this requirement be documented?

This is a classic M4 quoting bug.  The macro should quote the third
argument to AC_CACHE_CHECK (and really, should quote all the arguments).

The problem is that diversions do not work properly during arugment
collection so AC_REQUIRE (which depends on diversions) and many other
macros will not work properly if it is expanded during argument
collection.

Quote the arguments to AC_CACHE_CHECK and the prerequisite macros will
get expanded in the correct order.

(also WTF is with that stray AC_DEFINE outside of the macro definition?)

Cheers,
  Nick

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

[Nick Bowler]

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

If the Autoconf manual's portability notes are to be believed, then
such a rule is really not a good idea because on filesystems suporting
subsecond timestamp precision some "cp -p" implementations can create
the destination file with a strictly older timestamp than the source.

It's worth pointing out that even on filesystems supporting high-
precision timestamps, actual mtime updates usually have significantly
lower resolution (typically on the order of a millisecond or so).
Sufficiently fast make rules can frequently create many files with
exactly the same mtime.  Therefore considering equal timestamps to be
"up-to-date" is really the only reasonable option.

In cases where it is required to create two files with distinct mtimes,
the only real portable option I've found is to touch one of the files
in a loop and compare timestamps until they are different.

Cheers,
  Nick

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

[Nick Bowler]

On 2020-03-24, Ross Burton  wrote:
> As to why this is not broken with 2.69, I think I have a theory.
>
> If I build e.g. acl with both 2.69 and master, it's notable that 2.69
> has these lines in the output that do not exist in master:
>
>> checking how to run the C preprocessor... gcc  -E
>> checking for grep that handles long lines and -e...
>> /scratch/poky/hosttools/grep
>> checking for egrep... /scratch/poky/hosttools/grep -E
>> checking for ANSI C header files... yes

Probably that is it: the long-obsolete AC_HEADER_STDC, previously
used internally by AC_INCLUDES_DEFAULT, used AC_EGREP_HEADER.  The
AC_HEADER_STDC macro is now a no-op (and is not used at all within
Autoconf anymore), so that change is likely what made the first use
of AC_EGREP_HEADER the one inside the if condition, causing the
observed results.

> Something else was causing the egrep search to happen early in the
> build.  My hunch is that the same codepath exists in apt, and now
> isn't expanding egrep earlier in the configure run.
>
> Thanks for the explanation, I'll switch out if for AS_IF and move on.

Sounds great.  And thanks for all your effort in testing and fixing all
these packages.

Cheers,
  Nick

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

[Nick Bowler]

Hi Ross,

On 2020-03-24, Ross Burton  wrote:
[...]
> AC_CHECK_FUNC(statvfs,[HAVE_STATVFS=yes])
> dnl Arg, linux and bsd put their statfs function in different places
> if test x"$HAVE_STATVFS" != x"yes"; then
>AC_EGREP_HEADER(statfs,sys/vfs.h,[AC_DEFINE(HAVE_VFS_H)],[
>
> AC_EGREP_HEADER(statfs,sys/mount.h,[AC_DEFINE(HAVE_MOUNT_H)],[AC_MSG_ERROR(failed:
> Need statvfs)])
>])
> fi
> (and later looks for h_errno then fails)
>
> And the generated code does this:
>
> if test x"$HAVE_STATVFS" != x"yes"; then
> { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for grep that
> handles long lines and
> -e" >&5
> printf %s "checking for grep that handles long lines and -e... " >&6; }
> ...
>
> So the search for egrep only happens if statvfs isn't found by
> AC_CHECK_FUNC.  My understanding is that this isn't how AC_REQUIRE
> should be working, right?

No, this is exactly how AC_REQUIRE is supposed to be working.  The configure
script has a bug.  Now I'm not sure why this fails for you only with latest
autoconf, because AC_REQUIRE has worked like this for a very long time.  It
might have worked by luck because some earlier macro previously used
AC_PROG_EGREP, and maybe it no longer does.

The result of expanding AC_REQUIRE'd macros are hoisted to the outermost
macro expansion (although note that only macros defined with AC_DEFUN
and friends will participate in this process).

So if you have an open-coded shell "if" outside of any macro, then
within the if body, you expand a macro that uses AC_REQUIRE, then the
AC_REQUIRE'd macro gets expanded _within the if_.

This is almost never the desired behaviour because autoconf will
consider the macro expanded and will not expand the dependency at other
AC_REQUIRE sites, leading to the problem you see.

There are several options for configure authors can to avoid this
problem, including:

 (1) You can use AS_IF, which will cause m4 to hoist the dependency
 expansion outside of the conditional.
 (2) You can explicitly call all dependencies such as AC_PROG_EGREP
 outside of the if.

Obviously (2) is only possible if you know the dependencies in advance
(not so good for externally-updated macros) so I suggest using AS_IF.

Hope that helps,
  Nick

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

[Nick Bowler]

On 2020-03-23, Ross Burton  wrote:
> apt 1.2.31 builds fine with autoconf 2.69.  With git master:
>
> | checking for h_errno... configure: error: "not found."
>
> That code is:
>
> dnl HP-UX needs -d_XOPEN_SOURCE_EXTENDED for h_errno
> AC_MSG_CHECKING(for h_errno)
> AC_EGREP_HEADER(h_errno, netdb.h, [AC_MSG_RESULT(normal)],
>[CPPFLAGS="$CPPFLAGS -D_XOPEN_SOURCE_EXTENDED"
> AC_EGREP_HEADER(h_errno, netdb.h,
>[AC_MSG_RESULT(needs _XOPEN_SOURCE_EXTENDED)],
>[AC_MSG_ERROR("not found.")])
>])
>
> Obviously this is horrible, but it's out there.

Can you expand more on what is failing for you?  I just copy+pasted the
above code into the following configure script:

  % cat >configure.ac <<'EOF'
AC_INIT([test], [0])

dnl HP-UX needs -d_XOPEN_SOURCE_EXTENDED for h_errno
AC_MSG_CHECKING(for h_errno)
AC_EGREP_HEADER(h_errno, netdb.h, [AC_MSG_RESULT(normal)],
[CPPFLAGS="$CPPFLAGS -D_XOPEN_SOURCE_EXTENDED"
 AC_EGREP_HEADER(h_errno, netdb.h,
[AC_MSG_RESULT(needs _XOPEN_SOURCE_EXTENDED)],
[AC_MSG_ERROR("not found.")])
])

AC_OUTPUT
EOF

This seems to work perfectly fine with current autoconf master (ignoring
the slightly mangled output due to the example being a bit contrived):

  % autoconf --version
  autoconf (GNU Autoconf) 2.69.209-8a09
  [...]

  % autoconf

  % cat >netdb.h <<'EOF'
#if GATE && _XOPEN_SOURCE_EXTENDED
int h_errno;
#endif
EOF

  % ./configure CPPFLAGS='-I.'
  [...]
  configure: error: "not found."

  % ./configure CPPFLAGS='-I. -DGATE'
  [...]
  needs _XOPEN_SOURCE_EXTENDED

  % ./configure CPPFLAGS='-I. -DGATE -D_XOPEN_SOURCE_EXTENDED'
  [...]
  normal

Which appears to be exactly as expected for this configure test.

Cheers,
  Nick

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

[Nick Bowler]

On 20/03/2020, Ross Burton  wrote:
> URL:
>   
>
>  Summary: curl fails with autoconf master
>  Project: Autoconf
> Submitted by: rossburton
> Submitted on: Fri 20 Mar 2020 03:36:28 PM UTC
> 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:
>
> Curl cross-compiles fine with autoconf 2.69.  Swapping to autoconf master
> fails.
>
> It fails like this:
> checking if compiler is DEC/Compaq/HP C... no
> checking if compiler is HP-UX C... no
> checking if compiler is IBM C... no
> checking if compiler is Intel C... no
> checking if compiler is clang... no
> checking if compiler is GNU C... yes
> checking if compiler is LCC... no
> checking if compiler is SGI MIPSpro C... no
> checking if compiler is SGI MIPS C... no
> checking if compiler is SunPro C... no
> checking if compiler is Tiny C... no
> checking if compiler is Watcom C... no
> configure: error: in
> `/scratch/poky/work/corei7-64-poky-linux/curl/7.69.0-r0/build':
> configure: error: cannot run test program while cross compiling
>
> Yes, I'm cross-compiling, but the invocation of AC_RUN_IFELSE is guarded
> with
> a $cross_compiling check.

I suspect (without testing) the problem is the presense of
AC_REQUIRE([AC_RUN_IFELSE]) inside of CURL_RUN_IFELSE.

(Line 7292 of curl-functions.m4)

This use of AC_REQUIRE makes no sense at all.  With it there, if it
determines that there has been no prior expansion of AC_RUN_IFELSE in
the configure script, autoconf will output such an expansion at some
mostly-unspecified prior location with all arguments empty.

Such an expansion will cause the error you are seeing because the
action-if-cross-compiling argument is empty.

There are other weird uses if AC_REQUIRE in this file.  I suspect the
author(s) of this script have a serious misunderstanding about what
this macro does.

I imagine that it just happened to work by luck with old autoconf
because older versions of macros you are using happened to expand
AC_RUN_IFELSE themselves and this just happened to prevent any major
problems later in the configure script.

Hope that helps,
  Nick

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

[Nick Bowler]

On 1/17/19, Paul Gevers  wrote:
> On 14-01-2019 11:57, Matthias Klose wrote:
>> On 12.01.19 21:37, Chaim Zax wrote:
>>> Because autoconf can be used outside a Debian environment this solution
>>> might not work for everyone. Perhaps the AC_SEARCH_LIBS function should
>>> be extended so function arguments needed to check a library could be
>>> provided as well, or perhaps there is an other way to make it compatible
>>> with g++ 8.
>>
>> g++ 8 got more strict. You could check if that's the case for g++ 9 as
>> well (or
>> gcc-snapshot).  In any case, autoconf should be adjusted to avoid the
>> warning/error.
>
> Do you happen to know why g++ 8 happens to fail on this library and
> doesn't fail on other libraries we checked? Does g++ know which
> libraries it includes and is it pickier on those?

I'm not familiar with the library in question but the problem
appears to be specific to these __atomic_xyz builtins which seem
to get special treatment in g++.  Other builtins I tested do not
exhibit such failures.

There is no obvious way to disable the error in GCC: -fno-buitlin
appears not to affect these functions and -fpermissive does not resolve
the error at the call site.  AC_SEARCH_LIBS can present a simple
interface based on the assumption that correct declarations are not
required to test linking against a particular symbol in a library.

Clearly this assumption is not valid for these particular functions in
C++ mode, so it is likely that AC_SEARCH_LIBS simply cannot be used to
reliably probe for __atomic_xyz functions in libatomic.  In that case,
configure authors must use an alternate approach.  For example,

 - probing a different function from libatomic, if possible,
 - probing in C mode, if possible,
 - using AC_LINK_IFELSE with a valid test program, or
 - something else?

Cheers,
  Nick

Re: Potential bug in AC_CONFIG_SRCDIR

[Nick Bowler]

Hi Michael,
On 2019-01-07, Michael Cress  wrote:
> I am observing some strange behavior ( see comments in snippet ) with the
> AC_CONFIG_SRCDIR macro when using the configure.ac snippet below.
[...]
> #Define a subdirectory which contains the source files ( a separate Git repo
> )
> DCMSGSRCDIR=DockControllerImplv1_Messages_src
> AC_SUBST([DCMSGSRCDIR], [$DCMSGSRCDIR])
[...]
> #This also works
> AC_CONFIG_SRCDIR([$DCMSGSRCDIR/src/dockcontrollermsg.c])
> AC_CONFIG_SRCDIR([DockControllerImplv1_Messages_src/include/dockcontrollermsg.h])

The reason this works is because the second expansion of AC_CONFIG_SRCDIR
replaces the first one, hiding the problematic variable reference.

> # This ***does not*** work
>
> # This second use of the variable doesn't work and fails with ‘configure:
> error: cannot find sources (/include/dockcontrollermsg.h) in . or ..’.
>
> # Is this a bug?

I'd say no, although the documentation perhaps could be improved to
help the programmer understand the limitations.

> AC_CONFIG_SRCDIR([$DCMSGSRCDIR/src/dockcontrollermsg.c])
> AC_CONFIG_SRCDIR([$DCMSGSRCDIR/include/dockcontrollermsg.h])

This one fails because the last AC_CONFIG_SRCDIR expansion has the
problematic variable reference.

The "problem" is that AC_CONFIG_SRCDIR does its stuff very early in the
configure script: long before any normal shell assignments you put in
your script.  So DCMSGSRCDIR is not defined at the point it is used,
and so you get the wrong filename.

If you really want to reference shell variables in AC_CONFIG_SRCDIR you
need to be sure they are set in the DEFAULTS diversion.  But there seems
to be little point.  The only thing AC_CONFIG_SRCDIR really does is help
detect "operator error" if they botch the --srcdir option to configure,
so configure can print a better error message in this case.  Just point
it at any one file you want (ideally choose a file that is unlikely to
exist in other people's packages) and don't use any shell variables.

Cheers,
  Nick

Re: Setting a default value for an AC_ARG_VAR

[Nick Bowler]

On 12/16/18, Reuben Thomas  wrote:
> On Fri, 14 Dec 2018 at 14:51, Nick Bowler  wrote:
>
>>
>> If you want to set a value to a variable only if the variable is
>> unset, a typical way to do that in shell programming is:
>>
>>   : "${FOO=value-if-unset}"
>>
>> Or if you prefer also to set it the variable is _empty_ (i.e., including
>> the case where it is set to the empty string):
>>
>>   : "${FOO:=value-if-empty}"
>>
>
> So the answer seems to be "do it with shell". I still get confused (as
> here) with whether it's possible (or good style) to use shell directly,
> or whether there's something I should be doing with autoconf macros.

With Autoconf there are basically two distinct execution phases, and you
sometimes have choices about where your code lives:

  - You write m4 code, which runs on the developer's system, or
  - You write shell code, which runs on the user's system.

Or some combination of both.  Since "whether or not WORD_SIZE was set
in the user's configure environment" can't possibly be known by the
developer, you have to run it on the user system which means you have
to do it in shell.  Essentially everything you write in your configure.ac
which survives the m4 processing will end up in your configure script,
as shell program to be executed by the user.

Think of the Autoconf macros the same way you might think of standard
library functions in many programming languages: you can and probably
should use them when they help, otherwise it's totally fine to code
things up yourself.

Since the two forms above to conditionally assign variables are both
widely portable in practice and widely understood by shell programmers,
there's probably no advantage to Autoconf supplying a "standard" macro
to do it (AS_VAR_SET_IF could be used to do this too, but it's probably
overkill for your application).

> So in the end I have this:
>
> dnl Set size of word and address
> AC_ARG_VAR([WORD_SIZE],
>   [value of WORD_SIZE register [default: sizeof(long)]])
> AC_CHECK_SIZEOF([long])
> : "${WORD_SIZE=SIZEOF_LONG}"
> AC_ARG_VAR([ADDRESS_SIZE],
>   [value of ADDRESS_SIZE register [default: sizeof(size_t)]])
> AC_CHECK_SIZEOF([size_t])
> : "${ADDRESS_SIZE=SIZEOF_SIZE_T}"
>
> Does that look about right?

: "${WORD_SIZE=SIZEOF_LONG}" will, provided WORD_SIZE is previously
unset, set WORD_SIZE to the string SIZEOF_LONG.  That's probably
not what you wanted.  Try

  : "${WORD_SIZE=$SIZEOF_LONG}"

And likewise for the other assignment.

Hope that helps,
  Nick

Re: Setting a default value for an AC_ARG_VAR

[Nick Bowler]

On 12/14/18, Reuben Thomas  wrote:
> What's the right way to do this? I currently have:
>
> AC_ARG_VAR([WORD_SIZE],
>   [value of WORD_SIZE register [default: sizeof(long)]])
> if "$ac_cv_env_WORD_SIZE_set" != set; then
>   AC_CHECK_SIZEOF([long])
>   ac_cv_env_WORD_SIZE_value=SIZEOF_LONG
> fi
>
> which seems to work, but I'm conscious that I'm relying on undocumented
> variable names (ac_cv_env_*). I can't seem to get the same effect with, for
> example:
>
> AC_CHECK_SIZEOF([long])
> AC_SUBST([WORD_SIZE], [SIZEOF_LONG])
> AC_ARG_VAR([WORD_SIZE],
>   [value of WORD_SIZE register [default: sizeof(long)]])
>
> (the AC_SUBST overrides whatever AC_ARG_VAR does, it seems).

AC_ARG_VAR doesn't actually set the variable to anything.  That's up to
you.  In essence, the only thing it does is[1]:

  - Adds some help text to configure --help,
  - Causes configure to save its _original_ value from the environment,
so that config.status --recheck can replay that value and work properly,
  - When using a cache, it makes it an error to change the value in the
environment between configure runs (without cleaning first) because that
probably invalidates the cached results.
  - It also does AC_SUBST on the variable because why not.

If you want to set a value to a variable only if the variable is
unset, a typical way to do that in shell programming is:

  : "${FOO=value-if-unset}"

Or if you prefer also to set it the variable is _empty_ (i.e., including
the case where it is set to the empty string):

  : "${FOO:=value-if-empty}"

[1] 
https://www.gnu.org/software/autoconf/manual/autoconf.html#index-AC_005fARG_005fVAR-1209

Cheers,
  Nick

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

[Nick Bowler]

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

AC_TRY_EVAL is not documented in the Autoconf manual.

Drilling into the Autoconf source, we find that this is intentional:

  # The AC_TRY_EVAL and AC_TRY_COMMAND macros are dangerous and
  # undocumented, and should not be used.
  # They may be removed or their API changed in a future release.
  # Autoconf itself no longer uses these two macros; they are present
  # only for backward compatibility with previous versions of Autoconf.
  # Not every shell command will work due to problems with eval
  # and quoting, and the rules for exactly what does work are tricky.
  # Worse, due to double-expansion during evaluation, arbitrary unintended
  # shell commands could be executed in some situations.

If libtool is still using this macro, and it is causing problems,
then this does seem like a bug in libtool.  The solution would seem
to be for libtool to stop using AC_TRY_EVAL.

Cheers,
  Nick

Re: autoconf doesn't escape sed metacharacters in paths

[Nick Bowler]

On 6/18/18, Quasi Computational  wrote:
>  Reproduction:
>
> ```
> $ mkdir '\9'
> $ cd '\9'
> $ git clone https://github.com/haskell/network
> $ cd network
> $ git checkout 7e3f16d57b8745ef12cec8c9164bb91eeac90b5b # known-to-fail
> commit
> $ autoconf
> $ ./configure
> ```
>
> This fails for me with this line:
>
> ```
> sed: -e expression #1, char 400: invalid reference \9 on `s' command's RHS
> ```

Right, filenames containing backslashes are not supported by Autoconf,
see [1]; in particular, "These restrictions apply not only to the files
that you distribute, but also to the absolute file names of your source,
build, and destination directories."

However, I am sure if this specific issue is not too cumbersome to fix
then patches to do so would be accepted.

[1] 
https://www.gnu.org/software/autoconf/manual/autoconf.html#File-System-Conventions

Cheers,
  Nick

Re: autoreconf uses aclocal even when not needed

[Nick Bowler]

Hello,

On 3/22/17, Max Horn  wrote:
[snip]
> $ autoreconf -vif --no-recursive -I cnf/m4 .
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal -I cnf/m4  --output=aclocal.m4t
> Can't exec "aclocal": No such file or directory at
> /sw/share/autoconf/Autom4te/FileUtils.pm line 326.
> autoreconf: failed to run aclocal: No such file or directory
>
> I can "fix" this by installing automake, but this is deeply
> unsatisfactory.  Is there a better solution?

Not sure why this is a big problem, but if you supply aclocal.m4
yourself, autoreconf will not try to run the aclocal program to
generate it.

Cheers,
  Nick

Re: Broken example in autoconf manual

[Nick Bowler]

Hello,

On 2017-03-16, Max Horn  wrote:
> on
> https://www.gnu.org/software/autoconf/manual/autoconf.html#Using-System-Type
>
> this example is given:
>
>  case $host in
>alpha*-*-*)   AC_CONFIG_LINKS([dither.c:alpha/dither.c]) ;;
>powerpc*-*-*) AC_CONFIG_LINKS([dither.c:powerpc/dither.c]) ;;
>*-*-*)AC_CONFIG_LINKS([dither.c:generic/dither.c]) ;;
>  esac
>
> But that doesn't actually work; inserting it into configure.ac leads to this
> error:
>
> configure.ac:396: error: `dither.c' is already registered with
> AC_CONFIG_LINKS.

Nice catch.

[...]
> Which leaves me wondering how to achieve equivalent behavior correctly?

Probably the example could be written something like this (untested):

   case $host in
 alpha*-*-*)   dither_src=alpha ;;
 powerpc*-*-*) dither_src=powerpc ;;
 *-*-*)dither_src=generic ;;
   esac
   AC_CONFIG_LINKS([dither.c:$dither_src/dither.c]) ;;

Cheers,
  Nick

Re: bug#20733: coreutils build problem

[Nick Bowler]

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

OK, good to know.

[...]
 it's not the expand-to-nothing that is a problem, it is the actual
 omission:
 
 $ /bin/sh -c 'for a in ; do :; done'
 /bin/sh: syntax error at line 1: `;' unexpected
 $ /bin/sh -c 'for a in $nothing; do :; done'
 $

Right, I see that now in the doc patch you posted.  So in Autoconf this
might turn up if you generate the list with m4, but is highly unlikely
to be an issue for pure shell code.

Thanks,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: bug#20733: coreutils build problem

[Nick Bowler]

On 2015-06-04 13:34 -0600, Eric Blake wrote:
 [adding autoconf]
 
 On 06/04/2015 01:17 PM, Paul Eggert wrote:
  
  On 06/04/2015 09:41 AM, Michael Felt wrote:
GEN  src/coreutils.h
  /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
  
 
  Port to POSIX shell, which doesn't allow 'for i in ; do ...'.
 
 Actually, POSIX _does_ allow for missing words between 'in' and the
 terminator (; or newline) before 'do' (whether by a word that expands to
 nothing, or by omission of words), requiring that the body of the for
 statement is skipped in that case:
 
 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
 
 But it is also true that older shells did not always follow this rule,
 so you are indeed better off always supplying at least one word that
 won't be expanded into nothingness.
 
 Hmmm, I thought that autoconf would document it as a portability
 pitfall, but I don't see it under 'for' in this link:
 
 https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins

Yikes!

Some questions:

Do these problematic shells properly handle:

  for arg
  do
...
  done

when $# is 0?

If so, can we use the following as a workaround?

  set x words-that-might-expand-to-nothing; shift
  for arg
  do
...
  done

I suppose that might be hard to do in this /particular/ case, as it
looks like the error is coming from a make rule.  The Autoconf manual
quite emphatically says to avoid 'for arg; do ...' by using a newline
instead of a semicolon, a feat which is not easily done in make rules.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

[Nick Bowler]

On 2014-05-12 10:33 -0700, Jim Meyering wrote:
[...]
 I think the attach patch is sufficiently portable to do what I want.
 Does anyone see a way to make it more efficient with a POSIX shell?

 From e2a305bff2be376f6dd29e52a1d32636e0c22706 Mon Sep 17 00:00:00 2001
 From: Jim Meyering meyer...@fb.com
 Date: Mon, 12 May 2014 10:33:09 -0700
 Subject: [PATCH] egrep, fgrep: make wrappers portable to non-POSIX shells
 
 * src/egrep.sh (grep): Use sed in a subshell in place of the
 POSIX sh construct, ${0%/*}.  The latter is not portable to
 Solaris 10.  Reported by Paul Eggert in http://debbugs.gnu.org/17471
 ---
  src/egrep.sh | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)
 
 diff --git a/src/egrep.sh b/src/egrep.sh
 index f1b4146..0a374aa 100644
 --- a/src/egrep.sh
 +++ b/src/egrep.sh
 @@ -2,9 +2,10 @@
  grep=grep
  case $0 in
*/*)
 -if test -x ${0%/*}/@grep@; then
 -  PATH=${0%/*}:$PATH
 -  grep=@grep@
 +dirname=`echo $0|sed 's,//*[^/]*$,,'`

I'd write

   dirname=`expr x$0 : x'\(.*\)/'`

but mainly for style reasons...

 +if test -x $dirname/'@grep@'; then
 +  PATH=$dirname:$PATH
 +  grep='@grep@'
  fi;;
  esac
  exec $grep @option@ $@

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Faillure to autogenerate file on hpux

[Nick Bowler]

On 2013-03-31 11:01 +0100, Bastien ROUCARIES wrote:
 On Sat, Mar 30, 2013 at 5:01 PM, Bastien ROUCARIES 
 roucaries.bast...@gmail.com wrote:
[...]
  No we have a automake rules that do:
  $(PERLMAGICK)/quantum/@MAGICK_ABI_SUFFIX@.pm: 
  $(PERLMAGICK)/quantum/quantum.pm
  $(AM_V_GEN) $(LN_S) $(notdir $^) $@
  
  And it is surelly not portable ...
 
 Any idea to get portable basename shell command ?

Note also that $^ is not portable as it is also GNU make feature, along
with $(notdir ...).

But in this case it doesn't look like you need $^, or even basename.  I
think you can just replace the string (unfortunately, you'd need to see
the rest of the Makefile to be sure):

  $(notdir $^)
  
with:

  quantum.pm

and it will work just as well, and be portable.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Re-execute with the correct make implementation

[Nick Bowler]

On 2013-01-03 23:05 +0100, Stefano Lattarini wrote:
 On 01/03/2013 10:34 PM, Eric Blake wrote:
[...]
  Hmm, that goes back to one of the questions we asked about Automake-NG -
  is it possible to write a generic makefile that merely forwards all
  requests to gmake, and where all of the real magic of Automake-NG is in
  GNUMakefile, so that even if the user types 'make all' they still end up
  running 'gmake all' under the hood?
 
 For usual targets, that is easy.  I don't even think that must be done
 at Automake-NG level; one can simply use 'GNUmakefile.am' as Automake-NG
 input file (instead of the usual 'Makefile.am'), add 'GNUmakefile' to
 an AC_CONFIG_FILES invocation, and then hand-write a simple Makefile
 acting as a thin wrapper:
 
   TARGETS = all check clean distclean dist distcheck install uninstall
   .PHONY: $(TARGETS)
   $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@

Unfortunately, this kind of wrapper doesn't work particularly well.  If
the user runs something similar to:

  make -j2 all install

then the wrapper makefile will happily fork off two independent make
instances in parallel: one running gmake all and one running gmake
install.  The result will probably be catastrophic.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

[Nick Bowler]

On 2012-12-23 21:36 +, Reuben Thomas wrote:
 In my configure.ac, I have:
 
 AC_SUBST(PACKAGE) # so that automake can generate dependencies for 
 ${PACKAGE}*.rockspec
 AC_CONFIG_FILES(${PACKAGE}.rockspec)

While this is not related to your problem, note that your macro
arguments are underquoted.  Since the arguments are (presumably) not
meant to be subject to macro expansion, they should have one level of
quotation, as in:

  AC_SUBST([PACKAGE])
  AC_CONFIG_FILES([...])

The Autoconf manual includes a whole section on the gory details of M4
quoting.

Furthermore, AC_SUBST([PACKAGE]) is not required (but should not be
harmful) as Automake does this automatically.

 This works in getting the requisite dependency generated in Makefile.in:
 
 ${PACKAGE}-git-1.rockspec: $(top_builddir)/config.status
 $(srcdir)/${PACKAGE}-git-1.rockspec.in
 cd $(top_builddir)  $(SHELL) ./config.status $@
 
 But when I actually try to use the rule, it fails:
 
 $ make zee-git-1.rockspec
 cd .  /bin/bash ./config.status zee-git-1.rockspec
 config.status: error: invalid argument: `zee-git-1.rockspec'
 make: *** [zee-git-1.rockspec] Error 1
 
 As far as I can tell, this is because config.status doesn't get passed a
 value for PACKAGE.

I suspect (without testing) that config.status is actually looking
to generate a file called, literally, ${PACKAGE}.rockspec from
${PACKAGE}.rockspec.in.  This is wrong, because what you wanted was
for ${PACKAGE} to be replaced with the package name.

 AC_ARG_VAR doesn't seem to be relevant here, and I'm out of other ideas
 after searching online and reading the autoconf manual. What should I be
 doing here?

While I don't know if you can successfully use shell variables in
AC_CONFIG_FILES, there is another possibility in your case.
Autoconf defines the macro:

  AC_PACKAGE_NAME

which expands to the package name at M4 time.  This should be usable in
the argument to AC_CONFIG_FILES, with something like (untested):

  AC_CONFIG_FILES(m4_defn([AC_PACKAGE_NAME])[.rockspec])

Note the (lack of) quoting around the call to m4_defn: this is because
m4_defn produces an appropriately quoted string and we actually want
that macro to be expanded before passing the result to AC_CONFIG_FILES.
But the rest of the argument is quoted because that part should not be
subject to macro expansion.

Hope that helps,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Typo in shell substitution example in autoconf manual.

[Nick Bowler]

Hello,

I was reading the portability section of the autoconf manual and I
believe there's an error in one of the examples in §11.6: Shell
Substitutions.

https://www.gnu.org/software/autoconf/manual/autoconf.html#Shell-Substitutions

The examples in question are found at the end of the subheading
${var+value}, quoted here:

  Perhaps the easiest way to work around quoting issues in a manner
  portable to all shells is to place the results in a temporary variable,
  then use ‘$t’ as the value, rather than trying to inline the expression
  needing quoting.
  
$ /bin/sh -c 't=a  b\'\''}\\; echo ${a-$t}'
b  c'}\
$ ksh -c 't=a  b\'\''}\\; echo ${a-$t}'
b  c'}\
$ bash -c 't=a  b\'\''}\\; echo ${a-$t}'
b  c'}\

I had a double take upon reading this.  I think the output for all three
of those example commands should read

  a  b'}\

rather than

  b  c'}\

as it appears in the manual.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)