Ralf Jahr wrote:
Andrew Haley wrote:
Ralf Jahr wrote:
I try to build a cross-compiler for a mips-target.
Well, i assumed that I would get a compiler which can build executables.
Unfortunately but this does not work; I get the following error message:
/usr/cross-mips/lib/gcc/mipsel-elf/4.3.2/../../../../mipsel-elf/bin/ld:
crti.o: No such file: No such file or directory
collect2: ld returned 1 exit status
crti.o is part of the C library. You haven't installed a C library, so
your programs won't link.
OK, thanks for the inspiration. :-) I got newlibc to compile even
without being able to generate executables.
I can now generate executables and use objdump on them. But I get a
warning message:
/mipsel-elf-gcc -O3 hello.c -msoft-float -static
/usr/cross-mips/lib/gcc/mipsel-elf/4.3.2/../../../../mipsel-elf/bin/ld:
warning: cannot find entry symbol _start; defaulting to 0000000000400050
I think I can live with this. But if I want to use printf I get another
error:
(.text+0xd4): undefined reference to `printf'
collect2: ld returned 1 exit status
Even adding the compiled libc.a does not help:
Do you have any ideas how I can get rid of this error, too?
Ok, you now learned that producing executables requires a C library with
startups... But what is still required is some "real" target for "which"
to produce executables!
The 'mipsel' in the target name is the "cpu/endianess" type, the 'elf'
is only the object format, and these two don't yet define the interfaces
to the target system, its I/O-system, its memory layout, possible
'syscall' (calls to the 'opsys') etc.
The newlib C library has some "glue" libraries for some HW/firmware
systems like the PMON-monitor firmware on a MIPS-board, the 'libpmon.a'
probably was the name for this glue library. Another real target is an
IDT-borad with some IDT-monitor....
There are many ways to tell what that "real target" is, one of these is
to edit a default one into the GCC's 'specs' file. I myself have used
this because mainly producing executables to the MIPS-simulator coming
with the GNU debugger, 'GDB', and this can run apps made for IDT.
The important (edited) rows in my gcc-3.2.3 'specs' are :
--------------- clip ---------------------------------
*endfile:
crtend%O%s crtn%O%s -T idt.ld%s
*link:
%(endian_spec) %{G*} %{mips1} %{mips2} %{mips3} %{mips4} %{mips32}
%{mips64} %{bestGnum} %{shared} %{non_shared}
*lib:
*libgcc:
-lgcc
*startfile:
crti%O%s crtbegin%O%s
--------------- clip ---------------------------------
The long row after '*link' may be seen as two rows but there is only one
and then an empty row after each "spec"... Generally only the startfiles
(linked first) and the endfiles (linked last) are defined, the 'libgcc'
too, everything else is in that 'linker script' for the IDT-board,
'idt.ld', also this being provided in an installed newlib for mips*-elf.
The important thing in editing 'specs' is that it has ist own 'strict'
format :
<specname>
<the spec itself>
<empty line>
Those '%s' ("search and parse this") etc things were described
somewhere, the '-T' option for 'ld' should be described in the
linker documents...
When testing the edited 'specs', using a '-v' in the 'compile and link'
command will teach things... Putting a '-Wl,-verbose' onto it will
then show what happens during the link phase ("verbosely", with all
details)...
