Source: blt
Version: 2.5.3+dfsg-8
Tags: ftbfs patch upstream
Hello,
I noticed that blt fails to build from source when the CC variable is
exported. It does not matter what you export it to. It can be "cc",
"gcc" or "x86_64-linux-gnu-gcc" or even "false" or "true". The behavior
is always the same: It discovers a compiler and then fails to find any
header. With the help of Timo Roehling and Tobias Frost, I discovered
that the root cause for the problem resides in configure.in. The
AC_PROG_CC macro is conditionalized. When passing --with-cc, exporting
CC or setting the blt_cv_prog_cc cache variable, AC_PROG_CC is skipped
over. Doing so breaks all sorts of other checks. Instead, we should set
CC to whatever we prefer and then always run AC_PROG_CC. Then blt no
longer FTBFS. Please consider applying the attached patch and forwarding
it upstream.
Helmut
--- blt-2.5.3+dfsg.orig/configure.in
+++ blt-2.5.3+dfsg/configure.in
@@ -83,34 +83,20 @@
#
# -----------------------------------------------------------------------
-BLT_ENV_CC=$CC
-
#
# CC search order
#
# 1. command line (--with-cc)
# 2. environment variable ($CC)
# 3. cached variable ($blt_cv_prog_cc)
-# 4. check for program (AC_PROG_CC)
-# 4. default to cc
+# Discover using AC_PROG_CC
#
-AC_MSG_CHECKING([which C compiler])
if test "x${blt_with_cc}" != "x" ; then
CC=${blt_with_cc}
- unset ac_cv_prog_CPP
- unset ac_cv_prog_CC
-elif test "x${BLT_ENV_CC}" != "x" ; then
- unset ac_cv_prog_CPP
- unset ac_cv_prog_CC
-elif test "x${blt_cv_prog_cc}" != "x" ; then
- CC=${blt_cv_prog_cc}
- unset ac_cv_prog_CC
-else
- AC_PROG_CC
fi
-if test "x${CC}" = "x" ; then
- CC=cc
+if test "x$CC" = x && test "x${blt_cv_prog_cc}" != "x" ; then
+ CC=${blt_cv_prog_cc}
fi
case $target in
@@ -121,7 +107,7 @@
;;
esac
-AC_MSG_RESULT([$CC])
+AC_PROG_CC
unset blt_cv_prog_cc
AC_CACHE_VAL(blt_cv_prog_cc, blt_cv_prog_cc=$CC)
