This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: libstdc++ bootstrap failures on sparc-sun-solaris2.8 (analyzed)
- To: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Subject: Re: libstdc++ bootstrap failures on sparc-sun-solaris2.8 (analyzed)
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Tue, 31 Jul 2001 17:16:02 -0400
- cc: gcc 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>, Gabriel Dos Reis <gdr at codesourcery dot com>
>>>>> Gerald Pfeifer writes:
Gerald> Okay, I finally analyzed what's been going on:
Gerald> sparc-sun-solaris2.8/libstdc++-v3/src/gen-num-limits builds fine and works
Gerald> as expected, but unfortunately `make bootstrap' also builds and executes
Gerald> sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits which
Gerald> miserably crashes when run, as the machine in question is a 64-bit
Gerald> UltraSPARC IIi, alas one running a 32-bit kernel.
Gerald> Question 1: Why the heck are we building 64-bit sparcv9 stuff at all
Gerald> on such a host which by all practical means is 32-bit?
Gerald> Question 2: Now that we know what's going on, HOW DO WE FIX THIS?
Gee, this looks familiar. This is similar to the problems on AIX
which I have been complaining about for months. On AIX, we actually do
want to build the 64-bit library on the 32-bit host.
Again, V3 needs to go into a "cross-compiling" mode for
std_limits.h when generating a 64-bit library on a 32-bit host. I have
proposed that the build fall back to using the generic std_limits.h file
if gen-num-limits fails.
The other alternative is having configure treat the platform
entirely as a cross-build without newlib, requiring a lot of extra
definitions. See the *-linux* case in libstdc++-v3/configure.in.
This is the same problem hitting more and more targets.
David