| Message ID | 20101206183434.GU29412@tyan-ft48-01.lab.bos.redhat.com |
|---|---|
| State | New |
| Headers | show |
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
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
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
* 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
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
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
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
* 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
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
* 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
--- 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
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