Re: Cross-compiling MIPS programs...

[Kai Ruottu <kai dot ruottu at luukku dot com>]

David Morris wrote:
> 
> Ok all, I have (I think) a working compiler.  The problem?  It won't
> compile most programs.

 The problem? Perhaps it is that you are mixing compilation somehow
including linking too... A compiler compiles, assembler assembles,
linker links... You problem is in the linking...
 
> Here is the situation:  I have a simple test program I compile as
> follows:
> 
>     mips-idt-ecoff-gcc      test.c -o test
> 
> This works...wonderful.  I get a warning about setting the entry point
> to the default...this is minor as I have not yet setup a link script,
> and does not harm compilation.

 But you have some default linker script and link some default startup
('crt0.o') now... Using the '-v' tells what it does now. A compile would
have happened using the '-c' (compile only, don't link) option as you
already did:

> I next compile using a seperate linking stage...
> 
>     mips-idt-ecoff-gcc      -c test.c -o test.o
>     mips-idt-ecoff-ld       test.o -lgcc -lc \
>         -L/usr/gnu/test/mips-idt-ecoff \
>         -L/usr/gnu/test/mips-idt-ecoff/lib/gcc-lib/mips-idt-ecoff/2.95.3 \
>         -o test.o
> 
> This works with the same warning as above (huzzah!)

 Your link-command doesn't show any sanity, you link 'test.o' against the
'libgcc.a' and 'libc.a' and wish the output executable to be the same
'test.o'... The '-L' options should be before the '-l<libname>' ones...

> /usr/gnu/test/mips-idt-ecoff/mips-idt-ecoff/lib/libc.a(makebuf.o): In function ` __smakebuf':
> /usr/share/src/elf/build-gcc-2.95.3-mips-idt-ecoff/mips-idt-ecoff/newlib/libc/stdio/../../../../../gcc-2.95.3/newlib/libc/stdio/makebuf.c:93:undefined reference to `isatty'
> 
> In the FAQ, it says the problem is that on some targets (apparently
> mips included) the isatty, open, close, write, etc. routines are not
> in libc.a, as per the normal, and machine-specific routines must be
> linked in from libgloss libraries.

 The 'libgloss' is the interface to the target hardware, which either
is supported in newlib or not... The 'libgloss/mips' has the linker
scripts and i/f-routines to the supported HW. If your target board
isn't any of them, you must write the target support yourself, but
spying from the existing ones isn't a bad idea at all...

 Anyway when experimenting, you can choose any of the supported ones
and link your programs for it. The IDT-one isn't a bad choice, the
PMON-monitor neither... The simulator in GDB seems to emulate quite
many of these, if not all...

> Well, I have looked through and tried linking all libraries I can
> find, but nothing works.  I have tried dozens of suggestions from this
> list's archives, and from web searches, and nothing seems to work.
> 
> Can anyone who has dealt with mips cross-compilers help out and tell
> me what is wrong here?  Am I missing a library that must be linked in?
> Did I mis a step in compiling the compiler itself?  I tried using the
> mips-elf target as well for the cross compilation of gcc with the same
> result...

 You should try to see the stuff as Legos, building a house needs the
suitable pieces... An executable needs the startup (crt0.o), where the
program starts at the symbol name '_start' or something... This calls
the 'main' in your C-program. The 'main' returns to the 'crt0.o' and
calls 'exit' there... What else the 'crt0.o' should do is then a long
story and there are docs for this. The GNUPro docs and the 'embed.pdf'
available via :

  http://www.redhat.com/apps/support/documentation.html

isn't a bad place to start... Anyway all your links did miss this very
importand 'Lego piece' or component and it may be necessary for you to
implement it, so all the advices like "Be smart, never start" or "Never
do yesterday what should be done tomorrow" should be forgotten...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com