PATCH - Re: Troubles with current 3.3 and 21_strings/ctor_copy_dtor.cc

[Greg Schafer]

On Thu, Jul 17, 2003 at 02:40:56PM +1000, Greg Schafer wrote:
> > I wanted to apply the fix for 11528 to the branch too and I noticed that the
> > unpatched sources behave *very* strangely for me on this testcase: all the
> > physical memory is used and the system becomes unusable. Probably, after a
> > while it would crash, but I managed to stop 'make check' with CTRL-C.
> > 
> > Weird, never seen something like this before.
> > 
> > Is anyone seeing something vaguely similar?
> > 
> > My system is P4, 512 MB, linux2.4.20, glibc2.3.2.
> 
> Hi Paolo
> 
> I'm seeing similar here (except the machine manages to survive the memory
> exhaustion).
> 
> It looks to be configury related. I used to get this:-
> 
> checking for sys/stat.h... (cached) yes
> checking for sys/types.h... (cached) yes
> checking for getpagesize... (cached) yes
> checking for working mmap... (cached) yes
> checking for unistd.h... (cached) yes
> checking for sys/time.h... (cached) yes
> checking for sys/resource.h... (cached) yes
> checking for testsuite memory limit support... yes
> checking for setenv declaration... yes
> checking for setenv... (cached) yes
> checking for shared libgcc... yes
> checking versioning on shared library symbols... gnu
> updating cache ../config.cache
> 
> 
> 
> Now I get this:-
> 
> checking for sys/stat.h... (cached) yes
> checking for sys/types.h... (cached) yes
> checking for getpagesize... (cached) yes
> checking for working mmap... (cached) yes
> checking for shared libgcc... yes
> checking versioning on shared library symbols... gnu
> updating cache ../config.cache
> 
> 
> Notice the lack of "checking for testsuite memory limit support" (amongst
> other missing bits) ? That test will normally define _GLIBCPP_MEM_LIMITS in
> config.h. But because it is now undefined, the call to
> __gnu_cxx_test::set_memory_limits() is not working as pointed out by Phil
> Edwards.
> 
> My logs are sporadic, but the last time it worked for me was on the 26th of
> last month.
> 
> I'm not sure why the configury is failing but will try to investigate..

Ok, I found it :-)

The problems started when this patch was applied:-

http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02197.html

Looks like part of the configure.in was somehow missed. Tha attached patch
makes it work.

Could someone please apply to branch ASAP?

Thanks
Greg
-------------- next part --------------
diff -uNr gcc-3.3.1-cvs.orig/libstdc++-v3/configure.in gcc-3.3.1-cvs/libstdc++-v3/configure.in
--- gcc-3.3.1-cvs.orig/libstdc++-v3/configure.in	2003-06-22 09:53:57.000000000 +1000
+++ gcc-3.3.1-cvs/libstdc++-v3/configure.in	2003-07-17 16:36:45.000000000 +1000
@@ -87,7 +87,7 @@
 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
+  GLIBCPP_IS_CROSS_COMPILING=true
 
   # 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
@@ -397,7 +397,7 @@
   # 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
+  GLIBCPP_IS_CROSS_COMPILING=false
   CANADIAN=no
 
   # Check for available headers.