AC_FUNC_{M,RE}ALLOC are not cross-compiling aware

[Kang-Che Sung]

Found this bug on Autoconf 2.69

The AC_FUNC_MALLOC and AC_FUNC_REALLOC macros check for runtime
behaviors of `malloc` and `realloc` respectively. However, both checks
silently evaluate to "no" when cross-compiling.

This is a bug, because:
1. They do not emit a warning on cross-compiling mode. Something like
   "WARNING: result no guessed because of cross compilation"
2. They do not try to make a good guess (if possible) on whether the
   "--host" machine is using glibc or not. For example this
   StackOverflow question .
   Trying to see the presence of gnu_get_libc_version() or just
   grepping the string "GNU C Library" in host's libc.so is enough to
   make a good guess.
3. The silent result as the macros currently behave is not documented
   in manual. (If documented, then configure.ac writers will know this
   behavior is expected and will workaround on cross-compiling on our
   side.)

AC_FUNC_{M,RE}ALLOC are not cross-compiling aware

[Kang-Che Sung]

Found this bug on Autoconf 2.69

The AC_FUNC_MALLOC and AC_FUNC_REALLOC macros check for runtime
behaviors of `malloc` and `realloc` respectively. However, both checks
silently evaluate to "no" when cross-compiling.

This is a bug, because:
1. They do not emit a warning on cross-compiling mode. Something like
   "WARNING: result no guessed because of cross compilation"
2. They do not try to make a good guess (if possible) on whether the
   "--host" machine is using glibc or not. For example this
   StackOverflow question .
   Trying to see the presence of gnu_get_libc_version() or just
   grepping the string "GNU C Library" in host's libc.so is enough to
   make a good guess.
3. The silent result as the macros currently behave is not documented
   in manual. (If documented, then configure.ac writers will know this
   behavior is expected and will workaround on cross-compiling on our
   side.)

BUILD_OBJEXT in ax_prog_cc_for_build is broken

[Kang-Che Sung]

Hi, Autoconf Archive maintainers.

I'm not sure where to report this bug, so I CC'd both the Autoconf mailing
list
and the Autoconf Archive one.

The BUILD_OBJEXT variable (and perhaps BUILD_EXEEXT too) in
AX_PROG_CC_FOR_BUILD are broken in the modern Autoconf (2.69).

I found this when I'm trying to improve Flex's (the lexer generator's) build
system, and it had troubled me when I make the correct use of BUILD_OBJEXT
and
BUILD_EXEEXT variables.

Here are the steps to reproduce the bug:

```bash
git clone https://github.com/westes/flex flex
cd flex && git checkout v2.6.4
./autogen.sh
./configure --build=x86_64-buildpc-linux-gnu --host=$(gcc -dumpmachine)
grep 'BUILD_OBJEXT *=' src/Makefile
```

For the last line of output I expect 'BUILD_OBJEXT = o' or
'obj', but the actual result is empty.

This would cause a further build error if I start a custom build rule such
as:

```automake
# Simplified example
EXTRA_PROGRAMS = build-flex
build_flex_OBJECTS = build-scan.$(BUILD_OBJEXT) ...
build-scan.o: scan.c
$(AM_V_CC)$(CC_FOR_BUILD) ... -o $@ $<
build-scan.obj: scan.c
  $(AM_V_CC)$(CC_FOR_BUILD) ... -o $@ $<
```

The above will produce a "no rule to make 'build-scan.'" error or something
like that..

I have read the ax_prog_cc_for_build.m4 code, and the bug might be
something to
do with AC_EXEEXT being obsolete (it expands to empty). And as the result
there's no check and $ac_build_exeext and $ac_build_objext become empty.
(It's valid for $ac_build_exeext to be empty, but not for $ac_build_objext.)

There's no easy workaround for users' side.

How to fix this problem other than avoiding BUILD_OBJEXT and BUILD_EXEEXT
altogether?

Thank you.
Kang-Che Sung

Autoheader should ignore m4 "dnl" comments

[Kang-Che Sung]

This bug is a funny one, I think.

In flex (lexer) configure.ac, I use "dnl" comments within
AC_CHECK_FUNCS for inline notes, like this:

# 
AC_CHECK_FUNCS([dnl
pow dnl Used only by "examples/manual/expr"
setlocale dnl Needed only if NLS is enabled
reallocarr dnl NetBSD function. Use reallocarray if not available.
reallocarray dnl OpenBSD function. We have replacement if not available.
])
# 

But this syntax will make autoheader generate unneeded HAVE_ macros in
config.h.in:

/* Define to 1 if you have the `available.' function. */
#undef HAVE_AVAILABLE_

/* Define to 1 if you have the `by' function. */
#undef HAVE_BY

/* Define to 1 if you have the `dnl' function. */
#undef HAVE_DNL

The dnl comments should be ignored when generating config.h.in header,
or at least document that users should not add comments from within
AC_CHECK_FUNCS.

Note: Tested this with Autoconf 2.69 and Automake 1.15.1. Detailed
steps to reproduce:

$ git clone --depth 1 --branch v2.6.4 https://github.com/westes/flex flex
$ cd flex
$ autoheader
$ cat src/config.h.in

See the useless HAVE_ macros in the header.

Re: Autoheader should ignore m4 "dnl" comments

[Kang-Che Sung]

Allow me to re-describe the bug in a clearer way:

In the configure.ac in Flex (lexer) project, I used a quoted argument with
"dnl" comments in within AC_CHECK_FUNCS like this:

AC_CHECK_FUNCS([dnl
pow dnl Used only by "examples/manual/expr"
setlocale dnl Needed only if NLS is enabled
reallocarr dnl NetBSD function. Use reallocarray if not available.
reallocarray dnl OpenBSD function. We have replacement if not available.
])

After running autoreconf, the generated 'configure' script is correct:

for ac_func in dup2 memset pow regcomp setlocale strchr strdup strtol
do :
  as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
if eval test \"x\$"$as_ac_var"\" = x"yes"; then :
  cat >>confdefs.h <<_ACEOF
#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1
_ACEOF

fi
done

But config.h.in comes with unneeded HAVE_ macros such as:

/* Define to 1 if you have the `available.' function. */
#undef HAVE_AVAILABLE_

/* Define to 1 if you have the `by' function. */
#undef HAVE_BY

/* Define to 1 if you have the `dnl' function. */
#undef HAVE_DNL

The result I would expect is either:

(a.) Both 'configure' and 'config.h.in' generated correctly, without redundant
macros in the latter file.

(b.) Both files generated consistently, with 'dnl', 'by' and others
treated as function tokens in the former file. That is, the 'configure' script
"broken" like this.

for ac_func in dnl pow dnl Used only by "examples/manual/expr"
setlocale dnl Needed only if NLS is enabled
do :
#...
done

So that I would know I mustn't quote the argument if I had comments
within the AC_CHECK_FUNCS syntax.

> Note: Tested this with Autoconf 2.69 and Automake 1.15.1. Detailed
> steps to reproduce:
>
> $ git clone --depth 1 --branch v2.6.4 https://github.com/westes/flex flex
> $ cd flex
> $ autoheader
> $ cat src/config.h.in
>
> See the useless HAVE_ macros in the header.

That's it.

Re: Autoheader should ignore m4 "dnl" comments

[Kang-Che Sung]

On Fri, Feb 23, 2018 at 3:59 AM, Eric Blake <ebl...@redhat.com> wrote:
> On 02/21/2018 08:07 PM, Kang-Che Sung wrote:
>>
>> This bug is a funny one, I think.
>>
>> In flex (lexer) configure.ac, I use "dnl" comments within
>> AC_CHECK_FUNCS for inline notes, like this:
>>
>>  # 
>>  AC_CHECK_FUNCS([dnl
>>  pow dnl Used only by "examples/manual/expr"
>>  setlocale dnl Needed only if NLS is enabled
>>  reallocarr dnl NetBSD function. Use reallocarray if not available.
>>  reallocarray dnl OpenBSD function. We have replacement if not
>> available.
>>  ])
>
> Rather than waiting for an updated autoconf with the fix, you could instead
> workaround it in the meantime, by making it more obvious that your comments
> are just that:
>
> AC_CHECK_FUNCS(
> [pow ]dnl Used only by "examples/manual/expr"
> [seclocale ]dnl Needed only if NLS is enabled
> [reallocarr ]dnl NetBSD function. Use reallocarray if not available.
> [reallocarray ]dnl OpenBSD function. We have replacement if not available.
> )

I'm already aware that unquoting the argument will work, and thank you.
But I've proposed the workaround in Flex in a different way:
<https://github.com/westes/flex/pull/316/commits/08b34646bd51ce4ef9008b1c7de6dabe90700e48>

>
> Yeah, that's an unfortunate side effect of the current implementation, which
> treats AC_CHECK_FUNCS as a whitespace separated list of words and does NOT
> perform macro expansion on that list as you would expect.  It may be
> possible to fix autoconf, but the fix may be hairy; or it might not even be
> possible to fix, at which point, documentation would be the only thing to
> improve.
>

What I was complaining is the inconsistent behavior between generating
configure and generating config.h.in. Like I described in the follow-up mail,
I expect both files work or both files be broken the same way.