This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]