jack albert wrote:
I am under the impression that gcc ONLY compiles for
the host system you have installed gcc on (by default
gcc installations on linux machines). To compile gcc
for a different processor you need to cross compile
gcc for the particular target (in my case m68k).
To "make a crosstoolchain for it" could be more
right... This means producing at least the target
(m68k) binutils ('as', 'ld', 'nm','objcopy',...), the
target GCC and the target C library, usually the
'newlib' in the "embedded" cases... And quite
often also the GNU debugger, "GDB", with or
without some GUI (Insight, DDT,...), it coming
with a "CPU simulator", the PowerPC one has
"PSIM" integrated into GDB, the m68k/Coldfire/CPU32
used to have none, only separate sims available
elsewhere...
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 *think* I instead have to set up a full cross compiler tool
chain. Note the program I am attempting to compile is
a small program meant to be run on a Motorola mvme147
PowerPC.
What on earth the 'm68k' or 'm68030' have to do with the "PowerPC"? The
old Apple Macs used the m68k family CPUs but switched to use the PPC CPU
maybe 10 or so years ago...
What you need, a crosstoolchain for 'm68k-elf' or something or for
'powerpc-eabi'
or something? (These two being the most common in the m68k and powerpc
areas
nowadays...)
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.
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".... Using a
common driver for many GCCs doesn't sound sane in any way nowadays, not even
for just the same target... I myself have separate GCC drivers for each
GCC version,
the version seen as a '-<major_gcc_version>' like '-3.3', '-3.4',
'-4.0', '-4.1' "tail" or
"suffix" in their names. There is even a configuration option for
getting this
automatically:
|-program-suffix=|suffix
Appends suffix to the names of programs to install in bindir (see
above). For example, specifying --program-suffix=-3.1 would result
in `gcc' being installed as /usr/local/bin/gcc-3.1.
||
But it unfortunately works only with the native GCCs :
"As currently implemented, this option only takes effect for native
builds; cross compiler binaries'
names are not transformed even when a transformation is explicitly asked
for by one of these options."
say the current docs... The manual method maybe is to rename the
earlier ones and the new ones
after their installation, for instance the 'm68k-elf-gcc' into a
'm68k-elf-gcc-4.1' after building and installing
gcc-4.1.1 for the 'm68k-elf' target...
Also, I have a gcc binary file on a Sun machine (where
the original code was created). Is there a way to get
the original configuration that it was built with? For
example, what it was configured to be cross compiled
with (host and target system). The gcc binary was
simply re-created and I can't recreate the full
installation.
I didn't fully understand this... Maybe you asked if you could duplicate
the Sun-hosted toolchain
with a SuSE9.1/i586 hosted "identical" one (just the same binutils and
GCC versions being used)?
If these versions aren't horribly old but for instance made from
binutils-2.10 and gcc-2.95 sources,
that could be quite possible... Cannot be sure, recently I tried to
rebuild the Red Hat Linux 7.3's
'gcc-2.96-113' (patched 'gcc-2.96-20000731') sources on SuSE 9.2 and
it's 'bison' crashed with the
'gcc-2.96' 'c-parse.y' or something source file. A rebuild (as a
crosscompiler) on the real RHL7.3
then worked nicely... I think having built some gcc-2.95.3's on the
SuSE 9.2 but maybe they didn't
require reproducing their '.y' sources into '.c' and '.h'.
Sorry for the basic questions, but I need to fully
understand this before continuing...
Maybe you should first find out what that "mvme147" target has as its
CPU, a 'm68k' or a 'PowerPC'
family CPU :-) My 'm68k-elf' targeted crosstoolchain had only the :
kai@Dell:/usr/local/m68k-elf/lib> l *mvme*
-rw-r--r-- 1 root root 50602 2002-06-03 21:16 libmvme135.a
-rw-r--r-- 1 root root 50602 2002-06-03 21:16 libmvme162.a
-rw-r--r-- 1 5249 1002 2776 2002-02-02 01:27 mvme135.ld
-rw-r--r-- 1 5249 1002 2828 2002-02-02 01:27 mvme162.ld
in its support libraries stuff... So I think we are talking about a
PowerPC targeted toolchain and for
that there are even pre-made downloadable toolchains for Linux, Windoze,
Sun etc. hosts, one really
doesn't need to build them if not really wanting to do that. And
especially doesn't need to use a week,
a month, or even more to learn "how to build" :-) Many times that
"learning how to build" is the goal,
not only getting that toolchain, and people choose to use their paid
worktime for these studies and not
pay anything for anyone for that "teaching"... So I would suggest trying
those prebuilt toolchains until
knowing something about crosscompilers and that there are many different
CPUs, "elves" like "m68k-elf"
and its "powerpc-eabi" cousin not being in any way "real targets", and
so on, things which an embedded
engineer is expected to already know... Many times these build problems
are identical with a: "Should
a car really use gasoline although there already is a battery below the
hood to give power to the engine?"
I know all this being an educational problem, but a new car owner just
coming from the driver's school
demanding "no cost gasoline" from those who knew it being needed, on the
highway would sound a
little "odd".... :-) In the 80's when I learned to drive, it really
happened that in one lecture hour I had
to go out of the car and learn to fill the tank. But the hood was never
opened and what was there stayed
totally unknown, the cars' "Owner's Manual's" however teached about
these things... People who are
asking about headers, libraries, startups and linker scripts in C
compilers although claim to be embedded
engineers, are like car engineers asking what on earth those batteries,
tyres and windshields are for in
cars... BTW, my "car analogy" maybe came from one guy with two
doctorates in techical sciences and
also being educated to work as a car mechanics. He too saw it useful to
see the other subjects as if they
were "cars" :-)
The 'http://www.ocdemon.com' used to have prebuilt crosstoolchains for
ARM, PPC and MIPS....
