Error building mips-sde-elf crosscompiler

[Kai Ruottu]

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...