build of 3.4.0 failed in configure of libffi on alphaev6-dec-osf5.1

build of 3.4.0 failed in configure of libffi on alphaev6-dec-osf5.1

[Joe Buck]

An attempt to build GCC 3.4.0 on alphaev6-dec-osf5.1 failed,
because an unquoted variable in the configure file whose value
is either undefined or the empty string.

The following patch to the configure script (and yes, I know that this is
the wrong fix, since it's a derived file) allows configure to succeed.
This might be a bug in autoconf 2.13.

I restarted the build and will report later if it succeeds.

--- libffi/configure.orig	Sat Nov 22 05:41:32 2003
+++ libffi/configure	Fri Apr 23 09:03:21 2004
@@ -2497,7 +2497,7 @@
 	 
 	 
 
-if test $ac_cv_header_sys_mman_h != yes \
+if test "$ac_cv_header_sys_mman_h" != yes \
  || test $ac_cv_func_mmap != yes; then
    ac_cv_func_mmap_file=no
    ac_cv_func_mmap_dev_zero=no

Re: build of 3.4.0 failed in configure of libffi on alphaev6-dec-osf5.1

[Aaron Ucko]

Yep.

The bug seems to be in the definition of AC_FUNC_MMAP_BLACKLIST in
aclocal.m4, which could probably even get away with leaving out the
quotes provided that it first actually called
AC_CHECK_HEADERS(sys/mman.h) and AC_CHECK_FUNCS(mmap) rather than
assuming (incorrectly, it seems) that something had previously run
those checks.

Re: build of 3.4.0 failed in configure of libffi on alphaev6-dec-osf5.1

[Jim Wilson]

Joe Buck wrote:
> -if test $ac_cv_header_sys_mman_h != yes \
> +if test "$ac_cv_header_sys_mman_h" != yes \

I think the problem is a little more complex than this.

The code in question comes from AC_FUNC_MMAP_BLACKLIST in 
libffi/acinclude.m4.  This adds additional tests to see if mmap is 
usable in our context.  This starts with a simple test to see if 
configure already figured out that mmap is unusable, in which case we 
don't do any further tests.  Unfortunately, there are no checks for mmap 
at all before this point.  So the mmap variables are unset.  This causes 
the shell error you noticed.  I can see the same error in x86-linux 
output, if I look at the libffi configure/make output.

checking whether to enable maintainer-specific portions of Makefiles... no
/home/wilson/GCC/gcc/libffi/configure: line 4102: test: !=: unary 
operator expected
/home/wilson/GCC/gcc/libffi/configure: line 4103: test: !=: unary 
operator expected
checking whether read-only mmap of a plain file works... yes

Note that we continued with the mmap checks despite the shell syntax 
error.  This can be confirmed with a simple example.

sh-2.05b$ if test $foobar != yes; then
 > echo "no"
 > else
 > echo "yes"
 > fi
sh: test: !=: unary operator expected
yes

So the code is wqorking by accident on linux here.  We do want to 
perform the mmap checks even though the mmap variables are not set.

If we modify libffi/acinclude.m4 as you suggest, then we will no longer 
perform the mmap checks, and mmap will not be used as intended.  A 
possible way to fix this is to add checks to see if 
ac_cv_header_sys_mman_h is set to anything at all, and continue if it is 
not set.  Or perhaps reverse the sense of the tests, so we check for 
equality to no instead of inequality to yes.

However, I think the real fix here is to add checks for mmap before we 
reach this point.  So what we need to do is add
AC_CHECK_HEADERS (sys/mman.h)
AC_CHECK_FUNCS (mmap)
to ensure that the variables are defined before we reach this point.

It looks to me like the MMAP_BLACKLIST stuff was copied from the gcc 
configure without noticing that there was an undocumented dependence on 
the sys/mman.h and mmap checks.  For good measure, we should add 
comments to document this dependence.

We should also check to see if this same mistake was made anyplace else.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com