Patchwork Don't require C++ bootstrap compiler (PR bootstrap/46810)

login
register
mail settings
Submitter Jakub Jelinek
Date Dec. 6, 2010, 6:34 p.m.
Message ID <20101206183434.GU29412@tyan-ft48-01.lab.bos.redhat.com>
Download mbox | patch
Permalink /patch/74435/
State New
Headers show

Comments

Jakub Jelinek - Dec. 6, 2010, 6:34 p.m.
Hi!

The recent go addition resulted in C++ bootstrap compiler being required
unconditionally, because the new autoconf unordered_map/hash_map checks
require C++.

Fixed by only doing the checks when we must have a C++ compiler (i.e.
--enable-build-with-cxx or when the current stage includes Go FE (because
then either the bootstrap compiler has to include C++ for stage1, or
previous stage includes C++).

Bootstrapped/regtested on x86_64-linux and i686-linux, without go and with
go.  Ok for trunk?

2010-12-06  Jakub Jelinek  <jakub@redhat.com>

	PR bootstrap/46810
	* configure.ac: Don't AC_LANG_{PUSH,POP}(C++) if
	$ENABLE_BUILD_WITH_CXX is not yes and go is not
	among $enable_languages.
	* configure: Rebuilt.


	Jakub
Ralf Wildenhues - Dec. 6, 2010, 7:12 p.m.
Hello Jakub,

* Jakub Jelinek wrote on Mon, Dec 06, 2010 at 07:34:34PM CET:
> 	PR bootstrap/46810
> 	* configure.ac: Don't AC_LANG_{PUSH,POP}(C++) if
> 	$ENABLE_BUILD_WITH_CXX is not yes and go is not
> 	among $enable_languages.
> 	* configure: Rebuilt.
> 
> --- gcc/configure.ac.jj	2010-12-06 08:08:55.000000000 +0100
> +++ gcc/configure.ac	2010-12-06 12:32:34.000000000 +0100
> @@ -909,17 +909,31 @@ AC_CHECK_HEADER(pthread.h, [have_pthread
>  gcc_AC_C_CHAR_BIT
>  AC_C_BIGENDIAN
>  
> +# We shouldn't require C++ compiler unless necessary, which is
> +# if --enable-build-with-cxx has been given or if go is included in
> +# this stage.
> +gcc_have_cxx_support=no
> +if test "$ENABLE_BUILD_WITH_CXX" = "yes"; then
> +  gcc_have_cxx_support=yes
> +else
> +  case ,$enable_languages, in
> +    *,go,*) gcc_have_cxx_support=yes ;;

This duplicates information from gcc/go/config-lang.in, namely that
lang_requires_boot_languages contains c++.  A cleaner way would be to
extract that from there.  The current loop sourcing the config-lang.in
files from within gcc/configure.in happens only much later, and
reordering the header checks would be awkward too.  It may be a bit
tough to reject this patch for this reason; please allow some time for
other build maintainers to chime in before you commit.

> +  esac
> +fi
> +
>  # ----------------------
>  # Checks for C++ headers
>  # ----------------------
>  
> +if test $gcc_have_cxx_support = yes; then
>  AC_LANG_PUSH(C++)
>  
>  AC_CHECK_HEADERS(unordered_map)
>  AC_CHECK_HEADERS(tr1/unordered_map)
>  AC_CHECK_HEADERS(ext/hash_map)
>  
>  AC_LANG_POP(C++)
> +fi

Thanks,
Ralf
Paolo Bonzini - Dec. 6, 2010, 8:18 p.m.
On 12/06/2010 08:12 PM, Ralf Wildenhues wrote:
> This duplicates information from gcc/go/config-lang.in, namely that
> lang_requires_boot_languages contains c++.  A cleaner way would be to
> extract that from there.  The current loop sourcing the config-lang.in
> files from within gcc/configure.in happens only much later, and
> reordering the header checks would be awkward too.

It would make a lot of sense actually to operate on the config-lang.in 
as the first thing in gcc/configure.  Jakub or Ian, would it be okay for 
one of you to give it a shot?

Paolo
Ian Taylor - Dec. 6, 2010, 8:26 p.m.
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> This duplicates information from gcc/go/config-lang.in, namely that
> lang_requires_boot_languages contains c++.  A cleaner way would be to
> extract that from there.  The current loop sourcing the config-lang.in
> files from within gcc/configure.in happens only much later, and
> reordering the header checks would be awkward too.  It may be a bit
> tough to reject this patch for this reason; please allow some time for
> other build maintainers to chime in before you commit.

Ralf, is there any way to tell autoconf to just skip the tests if there
is no C++ compiler?  That is what I foolishly assumed is what would
happen here.  The results of the tests simply don't matter if there is
no C++ compiler.

Ian
Ralf Wildenhues - Dec. 6, 2010, 9:23 p.m.
* Ian Lance Taylor wrote on Mon, Dec 06, 2010 at 09:26:30PM CET:
[ AC_CHECK_HEADERS C++ tests ]
> Ralf, is there any way to tell autoconf to just skip the tests if there
> is no C++ compiler?  That is what I foolishly assumed is what would
> happen here.  The results of the tests simply don't matter if there is
> no C++ compiler.

I think Jakub's patch achieves just that, no?
The key is to remember that AC_LANG_PUSH/POP works at m4 level and is
ignorant of shell conditionals, so it may not cross them.
That, or I'm missing something else here.

Thanks,
Ralf
Ian Taylor - Dec. 6, 2010, 9:54 p.m.
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> * Ian Lance Taylor wrote on Mon, Dec 06, 2010 at 09:26:30PM CET:
> [ AC_CHECK_HEADERS C++ tests ]
>> Ralf, is there any way to tell autoconf to just skip the tests if there
>> is no C++ compiler?  That is what I foolishly assumed is what would
>> happen here.  The results of the tests simply don't matter if there is
>> no C++ compiler.
>
> I think Jakub's patch achieves just that, no?

No, what Jakub's patch does is skip the tests if we don't need a C++
compiler.  I am suggesting that configure simply fail the tests if it
doesn't find a C++ compiler, rather than erroring out as it does now.

Ian
Jakub Jelinek - Dec. 7, 2010, 2:39 p.m.
On Mon, Dec 06, 2010 at 01:54:29PM -0800, Ian Lance Taylor wrote:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> 
> > * Ian Lance Taylor wrote on Mon, Dec 06, 2010 at 09:26:30PM CET:
> > [ AC_CHECK_HEADERS C++ tests ]
> >> Ralf, is there any way to tell autoconf to just skip the tests if there
> >> is no C++ compiler?  That is what I foolishly assumed is what would
> >> happen here.  The results of the tests simply don't matter if there is
> >> no C++ compiler.
> >
> > I think Jakub's patch achieves just that, no?
> 
> No, what Jakub's patch does is skip the tests if we don't need a C++
> compiler.  I am suggesting that configure simply fail the tests if it
> doesn't find a C++ compiler, rather than erroring out as it does now.

The tests themselves would just fail, sure, but the first use of a test in
AC_LANG_PUSH(C++) (or the push itself) causes m4 to also add
AC_LANG_PREPROC(C++) etc. code, and that has hard errors if the C++
preprocessor (or compiler) is not found or not working.

	Jakub
Ian Taylor - Dec. 7, 2010, 2:45 p.m.
Jakub Jelinek <jakub@redhat.com> writes:

> On Mon, Dec 06, 2010 at 01:54:29PM -0800, Ian Lance Taylor wrote:
>> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
>> 
>> > * Ian Lance Taylor wrote on Mon, Dec 06, 2010 at 09:26:30PM CET:
>> > [ AC_CHECK_HEADERS C++ tests ]
>> >> Ralf, is there any way to tell autoconf to just skip the tests if there
>> >> is no C++ compiler?  That is what I foolishly assumed is what would
>> >> happen here.  The results of the tests simply don't matter if there is
>> >> no C++ compiler.
>> >
>> > I think Jakub's patch achieves just that, no?
>> 
>> No, what Jakub's patch does is skip the tests if we don't need a C++
>> compiler.  I am suggesting that configure simply fail the tests if it
>> doesn't find a C++ compiler, rather than erroring out as it does now.
>
> The tests themselves would just fail, sure, but the first use of a test in
> AC_LANG_PUSH(C++) (or the push itself) causes m4 to also add
> AC_LANG_PREPROC(C++) etc. code, and that has hard errors if the C++
> preprocessor (or compiler) is not found or not working.

Yes.  What I'm asking is: is there a way to make that not happen.  Is
there a way to just fail the tests when there is no C++ compiler, rather
than causing the configure script to error out.

Ian
Ralf Wildenhues - Dec. 7, 2010, 7:12 p.m.
* Ian Lance Taylor wrote on Tue, Dec 07, 2010 at 03:45:41PM CET:
> Jakub Jelinek <jakub@redhat.com> writes:
> > On Mon, Dec 06, 2010 at 01:54:29PM -0800, Ian Lance Taylor wrote:
> >> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> >> > * Ian Lance Taylor wrote on Mon, Dec 06, 2010 at 09:26:30PM CET:
> >> > [ AC_CHECK_HEADERS C++ tests ]
> >> >> Ralf, is there any way to tell autoconf to just skip the tests if there
> >> >> is no C++ compiler?  That is what I foolishly assumed is what would
> >> >> happen here.  The results of the tests simply don't matter if there is
> >> >> no C++ compiler.
> >> >
> >> > I think Jakub's patch achieves just that, no?
> >> 
> >> No, what Jakub's patch does is skip the tests if we don't need a C++
> >> compiler.  I am suggesting that configure simply fail the tests if it
> >> doesn't find a C++ compiler, rather than erroring out as it does now.
> >
> > The tests themselves would just fail, sure, but the first use of a test in
> > AC_LANG_PUSH(C++) (or the push itself) causes m4 to also add
> > AC_LANG_PREPROC(C++) etc. code, and that has hard errors if the C++
> > preprocessor (or compiler) is not found or not working.
> 
> Yes.  What I'm asking is: is there a way to make that not happen.  Is
> there a way to just fail the tests when there is no C++ compiler, rather
> than causing the configure script to error out.

Yes.  It is a wee bit hacky, but prepending the first C++ header check
with

  m4_pushdef([AC_MSG_ERROR], [m4_defn([AC_MSG_WARN])])[]dnl
  AC_PROG_CXXCPP
  m4_popdef([AC_MSG_ERROR])[]dnl

should achieve this effect.

Cheers,
Ralf
Ian Taylor - Dec. 7, 2010, 7:22 p.m.
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> Yes.  It is a wee bit hacky, but prepending the first C++ header check
> with
>
>   m4_pushdef([AC_MSG_ERROR], [m4_defn([AC_MSG_WARN])])[]dnl
>   AC_PROG_CXXCPP
>   m4_popdef([AC_MSG_ERROR])[]dnl
>
> should achieve this effect.

Yikes.

Which approach would you prefer--this one, or the compilation test I
sent out earlier?

Ian
Ralf Wildenhues - Dec. 7, 2010, 7:38 p.m.
* Ian Lance Taylor wrote on Tue, Dec 07, 2010 at 08:22:27PM CET:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> 
> >   m4_pushdef([AC_MSG_ERROR], [m4_defn([AC_MSG_WARN])])[]dnl

This should've been
      m4_pushdef([AC_MSG_ERROR], m4_defn([AC_MSG_WARN]))[]dnl

> >   AC_PROG_CXXCPP
> >   m4_popdef([AC_MSG_ERROR])[]dnl
> >
> > should achieve this effect.
> 
> Yikes.
> 
> Which approach would you prefer--this one, or the compilation test I
> sent out earlier?

The above has the advantage of not having to think about the exact
command line and cleanup, so I slightly prefer it.  Alternatively,
the clean way to write the other approach would be something like

AC_LANG_PUSH([C++])
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [])],
                  [AC_CHECK_HEADERS([C++ headers to be checked...])
                   ...])
...
AC_LANG_POP([C++])

Either one are preapproved after suitable testing.

Thanks,
Ralf

Patch

--- gcc/configure.ac.jj	2010-12-06 08:08:55.000000000 +0100
+++ gcc/configure.ac	2010-12-06 12:32:34.000000000 +0100
@@ -909,17 +909,31 @@  AC_CHECK_HEADER(pthread.h, [have_pthread
 gcc_AC_C_CHAR_BIT
 AC_C_BIGENDIAN
 
+# We shouldn't require C++ compiler unless necessary, which is
+# if --enable-build-with-cxx has been given or if go is included in
+# this stage.
+gcc_have_cxx_support=no
+if test "$ENABLE_BUILD_WITH_CXX" = "yes"; then
+  gcc_have_cxx_support=yes
+else
+  case ,$enable_languages, in
+    *,go,*) gcc_have_cxx_support=yes ;;
+  esac
+fi
+
 # ----------------------
 # Checks for C++ headers
 # ----------------------
 
+if test $gcc_have_cxx_support = yes; then
 AC_LANG_PUSH(C++)
 
 AC_CHECK_HEADERS(unordered_map)
 AC_CHECK_HEADERS(tr1/unordered_map)
 AC_CHECK_HEADERS(ext/hash_map)
 
 AC_LANG_POP(C++)
+fi
 
 # --------
 # UNSORTED
--- gcc/configure.jj	2010-12-06 12:09:22.000000000 +0100
+++ gcc/configure	2010-12-06 12:32:42.000000000 +0100
@@ -8424,10 +8424,23 @@  $as_echo "#define AC_APPLE_UNIVERSAL_BUI
  esac
 
 
+# We shouldn't require C++ compiler unless necessary, which is
+# if --enable-build-with-cxx has been given or if go is included in
+# this stage.
+gcc_have_cxx_support=no
+if test "$ENABLE_BUILD_WITH_CXX" = "yes"; then
+  gcc_have_cxx_support=yes
+else
+  case ,$enable_languages, in
+    *,go,*) gcc_have_cxx_support=yes ;;
+  esac
+fi
+
 # ----------------------
 # Checks for C++ headers
 # ----------------------
 
+if test $gcc_have_cxx_support = yes; then
 ac_ext=cpp
 ac_cpp='$CXXCPP $CPPFLAGS'
 ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
@@ -8610,6 +8623,7 @@  ac_compile='$CC -c $CFLAGS $CPPFLAGS con
 ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
 ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
+fi
 
 # --------
 # UNSORTED
@@ -17506,7 +17520,7 @@  else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17509 "configure"
+#line 17523 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17612,7 +17626,7 @@  else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17615 "configure"
+#line 17629 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H