Experimental patch for slow libstdc++ configure

Experimental patch for slow libstdc++ configure

[Zack Weinberg]

I would appreciate it if people who have a vendor shell that executes
libstdc++ configure unacceptably slowly, would try this patch.  I know
it doesn't look like it should have any effect -- explanations will be
forthcoming later, when I'm awake.

The patch might only partially solve the problem, so please let it run
to completion even if it's still very slow, then compare the result
with the unmodified tree.

You'll need to rebuild libstdc++-v3/configure after applying the patch.

zw

===================================================================
Index: libstdc++-v3/configure.in
--- libstdc++-v3/configure.in	2002/02/22 11:36:08	1.83
+++ libstdc++-v3/configure.in	2002/03/04 06:36:39
@@ -50,9 +50,15 @@ GLIBCPP_ENABLE_CXX_FLAGS([none])
 GLIBCPP_ENABLE_SJLJ_EXCEPTIONS
 GLIBCPP_ENABLE_CONCEPT_CHECKS
 
-
-if test -n "$with_cross_host" || test x"$build" != x"$host"; then
+if test -n "$with_cross_host" || test x"$build" != x"$host"; then 
+  # We are being configured with some form of cross compiler.
+  GLIBCPP_IS_CROSS_COMPILING=1
+else
+  GLIBCPP_IS_CROSS_COMPILING=0
+fi
 
+case $GLIBCPP_IS_CROSS_COMPILING in
+  1)
   # This lets us hard-code the functionality we know
   # we'll have in the cross target environment. "Let" is a
   # sugar-coated word placed on an especially dull and tedious hack, actually.
@@ -66,9 +72,6 @@ if test -n "$with_cross_host" || test x"
   # libgloss versus newlib crt0.o, etc. When all of this is done, all
   # of this hokey, excessive AC_DEFINE junk for crosses can be removed.
 
-  # We are being configured with some form of cross compiler.
-  GLIBCPP_IS_CROSS_COMPILING=1
-
   # If Canadian cross, then don't pick up tools from the build
   # directory.
   if test -n "$with_cross_host" && test x"$build" != x"$with_cross_host"; then
@@ -187,7 +190,8 @@ if test -n "$with_cross_host" || test x"
   # At some point, we should differentiate between architectures
   # like x86, which have long double versions, and alpha/powerpc/etc.,
   # which don't. For the time being, punt.
-  if test x"long_double_math_on_this_cpu" = x"yes"; then
+  case x"long_double_math_on_this_cpu" in
+    xyes)
     AC_DEFINE(HAVE_ACOSL)
     AC_DEFINE(HAVE_ASINL)
     AC_DEFINE(HAVE_ATAN2L)
@@ -215,13 +219,14 @@ if test -n "$with_cross_host" || test x"
     AC_DEFINE(HAVE_SQRTL)
     AC_DEFINE(HAVE_TANL)
     AC_DEFINE(HAVE_TANHL)
-  fi
-else
+    ;;
+  esac
+  ;;
+  n)
 
   # We are being configured natively. We can do more elaborate tests
   # that include AC_TRY_COMPILE now, as the linker is assumed to be
   # working.
-  GLIBCPP_IS_CROSS_COMPILING=0
   CANADIAN=no
 
   # Check for available headers.
@@ -247,7 +252,10 @@ else
 
   # Establish limits on memory usage during 'make check'
   GLIBCPP_CONFIGURE_TESTSUITE
-fi
+  ;;
+  *)  AC_MSG_ERROR([impossible value for GLIBCPP_IS_CROSS_COMPILING])
+  ;;
+esac
 
 # This depends on the possibly-skipped linker test above.
 GLIBCPP_ENABLE_SYMVERS([yes])

Re: Experimental patch for slow libstdc++ configure

[Zack Weinberg]

On Sun, Mar 03, 2002 at 10:38:21PM -0800, Zack Weinberg wrote:
> I would appreciate it if people who have a vendor shell that executes
> libstdc++ configure unacceptably slowly, would try this patch.

Argh.  That patch had a typo in it.  Please use this one instead.

zw

===================================================================
Index: libstdc++-v3/configure.in
--- libstdc++-v3/configure.in	2002/02/22 11:36:08	1.83
+++ libstdc++-v3/configure.in	2002/03/04 16:29:27
@@ -50,9 +50,15 @@ GLIBCPP_ENABLE_CXX_FLAGS([none])
 GLIBCPP_ENABLE_SJLJ_EXCEPTIONS
 GLIBCPP_ENABLE_CONCEPT_CHECKS
 
-
-if test -n "$with_cross_host" || test x"$build" != x"$host"; then
+if test -n "$with_cross_host" || test x"$build" != x"$host"; then 
+  # We are being configured with some form of cross compiler.
+  GLIBCPP_IS_CROSS_COMPILING=1
+else
+  GLIBCPP_IS_CROSS_COMPILING=0
+fi
 
+case $GLIBCPP_IS_CROSS_COMPILING in
+  1)
   # This lets us hard-code the functionality we know
   # we'll have in the cross target environment. "Let" is a
   # sugar-coated word placed on an especially dull and tedious hack, actually.
@@ -66,9 +72,6 @@ if test -n "$with_cross_host" || test x"
   # libgloss versus newlib crt0.o, etc. When all of this is done, all
   # of this hokey, excessive AC_DEFINE junk for crosses can be removed.
 
-  # We are being configured with some form of cross compiler.
-  GLIBCPP_IS_CROSS_COMPILING=1
-
   # If Canadian cross, then don't pick up tools from the build
   # directory.
   if test -n "$with_cross_host" && test x"$build" != x"$with_cross_host"; then
@@ -187,7 +190,8 @@ if test -n "$with_cross_host" || test x"
   # At some point, we should differentiate between architectures
   # like x86, which have long double versions, and alpha/powerpc/etc.,
   # which don't. For the time being, punt.
-  if test x"long_double_math_on_this_cpu" = x"yes"; then
+  case x"long_double_math_on_this_cpu" in
+    xyes)
     AC_DEFINE(HAVE_ACOSL)
     AC_DEFINE(HAVE_ASINL)
     AC_DEFINE(HAVE_ATAN2L)
@@ -215,13 +219,14 @@ if test -n "$with_cross_host" || test x"
     AC_DEFINE(HAVE_SQRTL)
     AC_DEFINE(HAVE_TANL)
     AC_DEFINE(HAVE_TANHL)
-  fi
-else
+    ;;
+  esac
+  ;;
+  0)
 
   # We are being configured natively. We can do more elaborate tests
   # that include AC_TRY_COMPILE now, as the linker is assumed to be
   # working.
-  GLIBCPP_IS_CROSS_COMPILING=0
   CANADIAN=no
 
   # Check for available headers.
@@ -247,7 +252,10 @@ else
 
   # Establish limits on memory usage during 'make check'
   GLIBCPP_CONFIGURE_TESTSUITE
-fi
+  ;;
+  *)  AC_MSG_ERROR([impossible value for GLIBCPP_IS_CROSS_COMPILING])
+  ;;
+esac
 
 # This depends on the possibly-skipped linker test above.
 GLIBCPP_ENABLE_SYMVERS([yes])