Re: Errors cross-compiling gcc for mipsel-elf

[Kai Ruottu <karuottu at mbnet dot fi>]

rherrell@twmi.rr.com wrote :
> Hi, 
>
> I'm trying to cross compile gcc 4.1.0 on Fedora Core 5 for a little
> endian mips processor, and I'm getting some errors.
>
> I'm using configure:
>
> ..././configure --program-prefix=mipsel-elf-
> --prefix=/opt/local/mipsel-elf/ --target=mipsel-elf
>   
The 'mips*-elf' targets are for generally undefined "targets", I would 
say that "an 'elf' is not a
real target, it is only the format for the object". The Tolkien fans may 
disagree...  But a target
like 'mipsel-linux-gnu' or 'mipsel-netbsd' would be a real target with 
real world defaults for
producing executables.  The 'mips*-elf' requires telling with a linker 
script what on earth the
real target is, but for MIPSEL/Linux there shouldn't be any ready-to-use 
linker script, only
ones for the PMON monitor firmware, the IDT board etc. with the usual 
'newlib' C library.
And this target may expect using the '--with-newlib', or then really 
knowing what one is doing
when not using newlib...

Furthermore your $prefix and $target choices lead to 
'/opt/local/mipsel-elf/mipsel-elf' as the
chosen $tooldir for this $target... The target stuff is in 'bin', 
'*include' and 'lib' in the $tooldir,
that stuff which the GCC uses.  For humans the '$prefix/bin', 
'/opt/local/mipsel-elf/bin' with your
choice, has those '$target-<tool>' executables, and when this is the 
default, your '--program-prefix='
option is vain because it doesn't cause any change to anything...  I 
would suggest using the
target-independent '/opt/local' as the common $prefix for this and other 
crosstoolchains for
other targets you maybe will build later... The '$target-' prefix in the 
executables in the
'$prefix/bin'  and the separate '$target' subdirs in '$prefix/lib/gcc' 
and '$prefix/libexec/gcc'
will take care about not overwriting one toolchain with components from 
another installed
later...  Changing the $prefix value unfortunately requires rebuilding 
and installing both binutils
and GCC.  If being unsure about the purpose for the $prefix, asking 
beforehand is better
than asking afterwards...

> binutils previously compiled and installed fine with this.
>
> I get:
>
> WARNING: No native atomic operations are provided for this platform.
> WARNING: They cannot be faked when thread support is disabled.
> WARNING: Thread-safety of certain classes is not guaranteed.
> configure: error: No support for this host/target combination.
>   

This probably comes when trying to get the extra libraries, 'libiberty' 
and 'libstdc++-v3'...
I would expect the missing '--with-newlib' in the GCC configure to lead 
into this error.
Generally you even don't need them, only the C library, for compiling 
and linking a "Hello
World"....  If the 'make all-gcc' succeeds,  "getting GCC" succeeds 
too...  Getting the
extra libraries made is totally optional although this will be tried as 
default. For C++ the
'libstdc++' is obligatory of course...

> Should I configure it a different way?  Right now, I just want to make a
> statically linked hello world binary that I can try to run on a
> linux-2.4 kernel on a mipsel processor as a test.
>   

This clause has nothing at all to do with the 'mipsel-elf' target. The 
right target name is
'mipsel-linux-gnu' and with this you require the glibc from/for the 
precise target. For
instance if the target system has the Debian's 'mipsel-linux' port on 
it, using the Debian-
made glibc-something for this MIPSEL-based target system in your 
crosstoolchain is
expected.  If you want to link statically, then only the glibc and 
kernel headers plus the
base 'crt*.o' startups plus the static 'libc.a' are needed from the 
target C library. But
copying the whole glibc is recommended, maybe you would like to try 
usual executables
which use the installed '.so' files at runtime...  Running the 
Linux/MIPSEL apps requires
the Linux/MIPSEL target system.

With the 'mipsel-elf' target the GNU debugger, 'GDB', includes a 
built-in simulator for
running linked executables and debugging them, and a stand-alone 
'mipsel-elf-run' one
for only running them...   So no "target system" would be required to 
see that "Hello World"
the linked 'mipsel-elf' application (for a PMON-monitor based board for 
instance) would
output....