rherrell@xxxxxxxxxxx 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....
