I have pushed the following change upstream which should resolve this problem. See http://hg.linux-ha.org/dev/rev/7dec8ce065ff
# HG changeset patch # User Simon Horman <ho...@verge.net.au> # Date 1278317503 -32400 # Node ID 7dec8ce065ff3a40ec07e0ef8c50f03d197a151d # Parent 41d9d1030e43aab4d705b3c9071e1b9420f35738 # HG changeset patch # User Simon Horman <ho...@verge.net.au> # Date 1278317064 -32400 # Node ID d43856c0c3eea8c80bbe284086da70fe81f743d3 # Parent 9437698a6f7773006a3531df034aa9c1f46d5415 low: unset CFLAGS in a dash-friendly way According to the dash man page, the only way to unexport a variable is to unset it. This also works in bash. For the record, the reason that CFLAGS is exported from the environment to configure and configure appends -Werror to the CFLAGS then it will be re-exported by configure and has been observed to cause trouble when configure runs a separate configure is the libltdl directory. Closes: Debian Bug #582874 - http://bugs.debian.org/582874 See: Debian Bug #582875 - http://bugs.debian.org/582875 Signed-off-by: Simon Horman <ho...@verge.net.au> diff -r 41d9d1030e43 -r 7dec8ce065ff configure.in --- a/configure.in Tue May 25 11:56:20 2010 +0200 +++ b/configure.in Mon Jul 05 17:11:43 2010 +0900 @@ -2035,11 +2035,12 @@ dnl no effect. However if CFLAGS was exported from the user's dnl environment, then the new CFLAGS will also be exported dnl to sub processes. This causes a problem when configure -dnl is run in the libltdl directory. Horms 16th July 2002 -dnl - +dnl is run in the libltdl directory. if export | fgrep " CFLAGS=" > /dev/null; then - export -n CFLAGS || true # We don't want to bomb out if this fails + SAVED_CFLAGS="$CFLAGS" + unset CFLAGS + CFLAGS="$SAVED_CFLAGS" + unset SAVED_CFLAGS fi if test "$GCC" = yes; then -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
