------- Additional Comments From wilson at specifixinc dot com 2004-11-11
00:40 -------
Subject: Re: [3.4/4.0 Regression] libstdc++ fails for
crosses
On Wed, 2004-11-10 at 13:11, mg_gentoo at yahoo dot com wrote:
> ------- Additional Comments From mg_gentoo at yahoo dot com 2004-11-10 21:11
> -------
> Jim, you expressed an interest in this bug a while back
Maybe on the gcc list? I don't recall this PR, and don't see any
comments from me in the the PR.
I think the key detail here is that you have to have a target C library
before you can build a target libstdc++. Of course, if you are
bootstrapping a build environment, then you need the target gcc before
you can build the target C library. This gets tricky when glibc is
involved. You need to first install the glibc headers so you can build
libgcc. Then you do a partial gcc build. You build only the compiler
and libgcc without the libraries like libstdc++. Then you use gcc to
build a provisional glibc. Then you can build a full gcc including
libstdc++. Then you build a full glibc. Then See Dan Kegel's crosstool
that automatically does this for you.
http://kegel.com/crosstool/
If you don't want to go through all of the trouble of bootstrapping an
entire build environment, there is a much simpler way to do this. Use a
sys-root. The sys-root must include header files and libraries for the
target. Gcc will then be able to find them, and link tests will work,
and libstdc++ will configure OK. If libstdc++ won't configure, then
something is missing from your sys-root.
There is another way to solve this problem which is to hand-code in
answers to all of the questions that the libstdc++ configure script
asks. This is what crossconfig.m4 tries to do. However, I doubt that
this is kept up to date. Every time the configure script changes, the
answers in crossconfig.m4 need to change to keep up to date. For most
targets, no one bothers to do that, and hence this is likely always out
of date. Since there are other better ways to get a cross compiler
built, this is probably not worth the trouble. One of the problems with
providing hand-coded answers is that the answers can be wrong if someone
has a system with non-standard packages on it. So this is usually a
solution of last resort. It may be worthwhile for some targets though.
Note that we use this same trick in libiberty, but there we don't have a
choice because libiberty has to be buildable without a C library. This
is must simpler to do though, as there are fewer questions asked by the
libiberty configure script, and the list of questions rarely changes,
and the answers to those questions also rarely change.
I would guess that the gentoo configure problem is because the host OS
does not have a multilibbed C library. If the x86_64 gentoo system does
not have both the 32-bit and 64-bit C libraries in /lib, then one of the
multilibbed libstdc++ builds will fail to link, and you end up with the
same "cross-compiler" problem. This has to be fixed as above, e.g. you
must provide a multilibbed glibc before you can do a multilibbed gcc
build, or else you have to build gcc/glibc together as per Dan Kegel's
crosstool.
Incidentally, the error message referring to GCC_NO_EXECUTABLES is a
misnomer. This gets printed if gcc_no_link is true, and
GCC_NO_EXECUTABLES does set gcc_no_link. However, gcc_no_link also gets
set by AC_PROG_CC which is the standard autoconf test for determining
whether the C compiler works. If autoconf determines that the C
compiler can not link, then it sets gcc_no_link. This explains why a
native build can see this "cross-compiler" problem. AC_PROG_CC fails to
link if there is something missing from your compiler environment, which
as I explained above, is most likely a missing C library.
I am not convinced that there is any bug here. I think the only problem
is people not understanding how to do cross compiler builds, which can
be much more complicated than native builds. My company has recently
done cross compiler builds for linux from gcc-3.4 and we didn't have any
problem. Many inexperienced gcc developers have been able to build
linux cross compilers by using Dan Kegel's scripts. Hence I don't
believe there is any real bug here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371
