This is the mail archive of the
mailing list for the libstdc++ project.
Re: V3 and cross-compiler (AIX 4.3 64-bit mode)
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: V3 and cross-compiler (AIX 4.3 64-bit mode)
- From: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>
- Date: Fri, 8 Jun 2001 20:30:53 +0200 (MEST)
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, Robert Boehne <rboehne at ricardo-us dot com>, Phil Edwards <pedwards at disaster dot jaj dot com>, Mark Mitchell <mark at codesourcery dot com>, Alexandre Oliva <aoliva at redhat dot com>, libstdc++ at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- References: <200106081811.OAA27578@makai.watson.ibm.com>
David Edelsohn writes:
> How is V3 configuration, specifically gen-num-limits, suppose to
> work in the context of a cross-compiler?
> AIX 4.3 and above provides support for 64-bit applications. All
> of the rest of the toolchain and libraries exist on 32-bit systems; 64-bit
> applications can be compiled and linked, but cannot be run. GCC supports
> that mode (-maix64) and it is one of the multilibs.
For the multilibbed systems I work on (i.e. Solaris 8 and IRIX 6), this is
handled by the toplevel config-ml.in: it checks if one can compile and link
a trivial program for every multilib tried, and removed ones where this
does not work. There should probably be another test (optionally) checking
that the resulting program can run, too.
This doesn't help for your problem, unfortunately, but prevents the users
from nasty surprises such as bootstrap failures that late in the game.
There's one related problem in this context, though: while config-ml.in is
used for boehm-gc, libf2c, libffi, libiberty, libjava, libobjc,
libstdc++-v3, and zlib, it is not currently used in gcc's configure.in
itself. This can lead to the mentioned nasty surprises if one tries to
build gcc for a multilibbed configuration (like IRIX 6 with n32 and n64 or
Solaris 7/8 with sparcv7 and sparcv9) where there are systems that have
e.g. libc for both ABIs installed and others that have not (e.g. an SGI
that cannot run the 64-bit kernel or a non-UltraSPARC sun). The bootstrap
seems to procede normally up to the point where gcc attempts to link
libgcc_s.so, which tries to link in libc and fails ;-( This is a new
failure mode compared to GCC 2.95, since it only happens because now
there's this attempt to link a non-default multilib program, while this
didn't happen with an archive-only libgcc.
It is possible to work around this problem by configuring gcc with
--disable-multilib in this case (and this problem and workaround should be
documented in the installation notes if this is required), but given that
config-ml.in already provides the infrastructure to correctly deal with
this case, it would be better to integrate this into gcc's configure.in.
I had a quick look at this, but couldn't easily see how to do this. Since
this is Alexandre's code and he's the master of configury anyway, maybe he
can come up with a patch?
> For the AIX 4.3 multilibs, limitsMEMBERS.cc is (should be)
> uniformly identical. With Rainer's mknumeric_limits change, V3
> configuration now does not create an incomplete file, butthe build stops.
> How is one suppose to create limitsMEMBERS.cc for a
> cross-compiler? Is there any way to teach V3 configuration to re-use the
> 32-bit limitsMEMBERS.cc instead of failing to run a 64-bit application on
> a 32-bit system?
Of course this would have to be done on a case-by-case basis. There's no
way of knowing in advance if two multilibs act identically for
limitsMEMBERS.cc (or any other program to be run on the target system).
For example, when the IRIX 6 gcc supports all three ABIs/multilibs
(i.e. O32. N32, and N64), long double will be different depending on ABI
(64-bit for O32, 128-bit for N32 and N64).
Rainer Orth, Faculty of Technology, Bielefeld University