Understand cross compiling

Kai Ruottu karuottu@mbnet.fi
Wed Aug 16 19:16:00 GMT 2006

Kai Ruottu wrote:
> jack albert wrote:
>> How come I can still specify -m68030 on my i386
>> system? I would expect compilation to fail, but it
>> doesn't. Did it really compile for the i386 processor
>> or the m68k? (I can't tell since it's supposed to run
>> on the m68k - but I have other problems so I can't run
>> it just yet). My confusion is the fact that it *looks*
>> like I can compile for the m68k processor on my
>> default gcc installation (Suse 9.1).
> This doesn't sound possible, my SuSE 9.2 one gave :
> kai@Dell:/data1/home/kai-old/test/hello> gcc -v
> Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.4/specs
> <snip>
> gcc version 3.3.4 (pre 3.3.5 20040809)
> kai@Dell:/data1/home/kai-old/test/hello> gcc -m68030 -o hello_m68k 
> hello.c
> cc1: error: invalid option `68030'
> and your 9.1 one GCC should behave identically...  Only a real m68k 
> targeted
> GCC understands that '-m68030' option.

> I also do not understand the -b option from the gcc
> man page. How does gcc know to use a different gcc
> compiler installed somewhere else.
After using that '-b' to tell the "target", the native SuSE 9.2 'gcc' gave :

kai@Dell:/data1/home/kai-old/test/hello> gcc -b m68k-elf -m68030 -o 
hello_m68k hello.c
gcc: couldn't run `m68k-elf-gcc-3.3.4': No such file or directory

which gave the necessary clue to have just the same GCC version for the 
"target"! After
symlinking my 'm68k-elf-gcc-3.3' to be seen also as 'm68k-elf-gcc-3.3.4' 
(it was '3.3.5'),
the compile "succeeded" :

kai@Dell:/data1/home/kai-old/test/hello> gcc -b m68k-elf -m68030 -o 
hello_m68k hello.c
/usr/local/m68k-elf/bin/ld: warning: cannot find entry symbol _start; 
defaulting to 80000080
/usr/local/m68k-elf/lib/libc.a(makebuf.o)(.text+0x80): In function 
: undefined reference to `isatty'
/usr/local/m68k-elf/lib/libc.a(sbrkr.o)(.text+0x10): In function `_sbrk_r':
: undefined reference to `sbrk'
/usr/local/m68k-elf/lib/libc.a(writer.o)(.text+0x18): In function 
: undefined reference to `write'
/usr/local/m68k-elf/lib/libc.a(closer.o)(.text+0x10): In function 
: undefined reference to `close'
/usr/local/m68k-elf/lib/libc.a(fstatr.o)(.text+0x14): In function 
: undefined reference to `fstat'
/usr/local/m68k-elf/lib/libc.a(lseekr.o)(.text+0x18): In function 
: undefined reference to `lseek'
/usr/local/m68k-elf/lib/libc.a(readr.o)(.text+0x18): In function `_read_r':
: undefined reference to `read'
collect2: ld returned 1 exit status

 That I wrote that "succeeded", tells just what I meaned with that 
"ignoracy about the
basic know-how" among some so-called embedded engineers.  How a computer 
talks with the world via I/O devices, how it uses memory etc., was once 
teached in those
"embedded programming" courses and the engineers knew these things should be
implemented by them or with something existing (linker scripts and 'glue 
libraries' for
some HW board)

Ok, even the proper GCC driver, the 'm68k-elf-gcc-3.3.4' in the previous 
case is necessary,
so my first guess was wrong :
> This is probably some ancient option from the age when even 50-100 
> kbytes more
> for a separate 'gcc', 'g++' etc. drivers was "too much disk consuming"....

But the next "opinion" :
> Using a common driver for many GCCs doesn't sound sane in any way 
> nowadays, not even
> for just the same target...
was expressed as :

"The -V and -b options work by running the <machine>-gcc-<version> 
executable, so there's no real
reason to use them if you can just run that directly."

in the GCC docs.  So the only reason could be that one only can vary the 
'CC' options, the
'CC' must be 'gcc' always in the system, all 'Makefile's use only 
'$(CC)' and it is there always
that 'gcc'.  Or something....  The reasons come from the question: "Why 
someone cannot use
something like 'powerpc-eabi-gcc' in compiles?"  If someone can answer 
to that, the reason to
use the 'gcc -b $target' instead of '$target-gcc' has been found!

More information about the Gcc-help mailing list