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!
