19.7.2014 14:04, Anders Montonen kirjoitti:
On Jul 13, 2014, at 20:04, Kai Ruottu wrote:
13.7.2014 14:01, Anders Montonen kirjoitti:
I am trying to build a GCC 4.9.0 toolchain targeting mips-sde-elf on a OS X 10.7 host. Building the first stage compiler works fine, but trying to build the final compiler always ends with an error.
What on earth "first stage" and "final" compilers? Cross GCCs for embedded targets using newlib should
succeed in one build stage when the host CC is GCC, a native or a cross one (Canadian Cross).
Call it a bootstrap compiler if you wish. Building in one stage produces the same error. GCC 4.9.1 also behaves the same.
Yes, the problem isn't in the build method. My habit is to behave as a
dissident what comes to the weird
'crosstool*' methods borrowed from the 1917-1939 and later theories,
about avoiding everything which
is already made, here for the target (but not for the build or host)
system if there are sources for something.
Needing the prebuilt C library for a system target (one which has the
native GCC as the default type) during
the cross GCC build has been the reason why these multi-stage methods
were invented, in cases when the
target system (created from scratch) doesn't yet exist - there can be
hundreds of similar or compatible
systems already but one isn't allowed to borrow anything from them. But
when people use the same methods
with already existing targets like Linux distros which already have
their glibcs, X11-libs etc., things will become
really absurd when in these cases the cross GCC is only another
incarnation of the earlier native GCC, on another
host. And the build will happen in only one stage, usually with the
native GCC of the host system, making only
binutils and GCC targeted for the target. Everything else being copied
from the target system, not being rebuilt
from any sources. Similarly a cross GCC for an embedded target (no
native GCC for that) is aimed to be built
in only one stage, or at least should be possible always. Either with
an existing old target C library or if the
target C library is newlib, producing also it during the GCC build. Then
there are those '--without-headers' etc
options which allow one to build without any headers for the target seen
during the GCC build.
Ok, I tried the same as you: To produce a 'mips-sde-elf' targeted
crosstoolchain from scratch on my CentOS 6.5
x86_64 laptop build host but using a CentOS 5.8 i386 targeted cross GCC
(4.6) as the host GCC, ie producing
the toolchain binaries for a 32-bit system, not for the 64-bit build
system. Producing these for the native host
was expected to succeed just as well...
First I made only the host binaries, binutils and the bare GCC, the
latter with :
make all-gcc
No problems... Then the libgcc variations, quite many!, for the target,
'mips-sde-elf' :
make all-target-libgcc
Again no problems... But you seemingly had problems in this phase :(
Some time later I continued the build with "everything" :
make
and then with installing the produced stuff :
make install
The last two phases required a whole night! Expected things being ready
when waking up but it was still doing
the last libs... In any case there were no problems.
So it looks like that the Makefiles etc made vith the OS X native tools
don't work, making them right will fail
somehow... I don't know whether there is any quarantee for things
always working on a OS X build system.
Or for a Sun Solaris2, old SVR4, Cygwin, MinGW/MSYS etc. "Unix-like"
build systems. Generally I know nothing
about the OS X systems as the build systems. For Cygwin and MinGW,
Solaris2 etc. my habit has been to stay
with the surely working Linux build system and just make a
crosstoolchain for the required new host and then
use it when making things for that host. Making a crosstoolchain for OS
X has been some kind of black magic
some years ago though, maybe it would succeed now. Earlier the GNU
binutils didn't work for OS X/Darwin, Apple had its own "custom GCCs"
etc. which quite soon caused people to forget producing anything for
this host :(
So cross building toolchains for OS X host may still be a bad idea...
But if one produces a 'mips-sde-elf' targeted cross GCC on a Linux host
and on an OS X host, the only difference
between them should be only in what was produced during the binutils
build and during the 'make all-gcc' build.
Everything else being totally identical if the binutils and GCC sources
are just the same. So nothing disables you
to build a 'mips-sde-elf' targeted toolchain on some working Linux build
host and then only binutils and the bare
GCC on the OS X build host, and then copy the
'$prefix/mips-sde-elf/include', '$prefix/mips-sde-elf/lib' and the
'$prefix/lib/gcc/mips-sde-elf' from the Linux host to the OS X host.
Not wondering why building libgcc and most
probably all the other target libraries doesn't succeed on the OS X
host. Of course a bug report for this could be
nice it there are people who will try to get things to work also on the
OS X host...
Maybe replacing one or more of the original OS X native tools with
equivalent GNU tools is what should be done.
That one needs the GNU make is quite clearly told in the "GCC
Prerequisities" but there may be other tools to
check before the build system is the "expected one" and behaves as
expected...
