This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++ bootstrap failures on sparc-sun-solaris2.8 (analyzed)
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: libstdc++ bootstrap failures on sparc-sun-solaris2.8 (analyzed)
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Tue, 31 Jul 2001 23:05:21 -0700 (PDT)
- cc: David Edelsohn <dje at watson dot ibm dot com>, Gabriel Dos Reis <gdr at codesourcery dot com>, Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, Alexandre Oliva <aoliva at redhat dot com>, Jan Hubicka <jh at suse dot cz>
Huh. I am not objecting to this approach. This is Gaby's baby: he needs
to figure out how to fix it so that everybody's happy. I think it's
gotten too complex as well.
.... passing the buck,
benjamin
> I think std_limits.h should be entirely pregenerated, based on the
> architecture, and stored in config/cpu or config/os. (Perhaps only
> a small bit needs to be stored there, and the rest can be entirely
> generic. For example, maybe you could just do `#define BITS 32' in
> config/cpu. The details aren't important.)
>
> Then gen-num-limits would never be run during any build of any
> kind. It would only be run to generate a new file, when doing a
> new port, and then the output would be stored away.