This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Understand cross compiling


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 `__smakebuf':
: 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 `_write_r':
: undefined reference to `write'
/usr/local/m68k-elf/lib/libc.a(closer.o)(.text+0x10): In function `_close_r':
: undefined reference to `close'
/usr/local/m68k-elf/lib/libc.a(fstatr.o)(.text+0x14): In function `_fstat_r':
: undefined reference to `fstat'
/usr/local/m68k-elf/lib/libc.a(lseekr.o)(.text+0x18): In function `_lseek_r':
: 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 program
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!




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]