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

Submitted by Jakub Jelinek on Dec. 6, 2010, 6:34 p.m.

Details

Message ID 20101206183434.GU29412@tyan-ft48-01.lab.bos.redhat.com
State New
Headers show

Commit Message

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

Comments

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 hide | download patch | download mbox

--- 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