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