Can't build gcc-3.0.1 for m68k-coff
Wed Oct 17 08:01:00 GMT 2001
> But what is the system 'm68k-coff' you now want your executables to run
> on? When you have a clue about that, you can edit your 'specs' file by
> putting a default 'target system' into it. The 'specs'-file which the 'xgcc
> -dumpspecs' produces during the build is partially bullshit because nobody
> has had a clue about what could be the suitable default target for
> 'm68k-coff' executables. The '*_SPEC' settings in the config files are for
> 'nothing specified' as the real target.
> The default CPU is the m68020/m68881 combination, so putting a MVME-board
> or something which has the default CPU on it, would then cause all the
> CPU32 or Coldfire users to scratch their heads and ask here why the
> compiled and linked programs (for m68020/m68881 and the MVME-hardware)
> don't run on their target boards...
Yes, I'm aware of this. However shouldn't gcc compile with m68k-unknown-coff,
then different board variations can be setup later?
> What comes to the "build a cross compiler for m68k-coff with gcc-3.0.1",
> you have done it when the 'gcc'-subdir was passed! Believe or not, this is
> the 'compiler' case... Now you can install your new GCC, build newlib with
> all the target board support libraries (BSPs), ie. the 'glue libraries',
> besides the 'libc.a's and 'libm.a's for quite many m68k-CPU-variations
> (m6800, m68020, mcpu32, m5200,....).
I suspected this, but without knowing the internal details of gcc and how it
compiles, an error normally means its not going to work.
> Hmmm, sounds like ELF-stuff ("Exception_Handling_Frame_Begin"), so :
These errors were apparently related to newlib. By doing a 'make all install'
in the existing build-newlib directory, then building gcc again, all worked.
> Currently there aren't any kind of sane target in the defaults, so the
> build doesn't know which m68k-board and its glue-library should be used
> when linking. Everything has been left to the embedded engineer who really
> should know these things about linker scripts, startups, libraries,
> interfacing with the hardware etc. At least the primary-level things like
> "What are the headers?", "What are the C-libraries", "Which functions a
> C-program uses to communicate with the hardware?" Any course called "Using
> C in embedded programming" or something is expected to handle these
> things... If not, where is the sanity in these university etc. courses?
There were no courses on embedded programming with C at my college. But I
agree they should exist.
> For self-education books like "Programming Embedded Systems in C and C++"
> by Michael Barr or "Programming with GNU Software" by Mike Loukides and
> Andy Oram (both from O'Reilly) could be recommended. Probably there are
> others, but the idea about the reader becoming aware of the memory maps,
> interfacing etc. things should be present in both...
I learned from "Embedded Systems Programming in C and Assembly" and "Embedded
Systems Building Blocks". These give a basic understanding, but not the
specifics of the GNU tools. Anyone know where I can get a copy of
"Programming with GNU Software", Amazon.com and local bookstores don't have
> When you even tried to build newlib at the same time with GCC, you had a
> blind trust that "it should work straight from the box because the GNU guys
> have made these sources". "Just prepare the sources, run a script from some
> FAQ and everything works and the whole toolkit will be built"...
There should be a listing of known working combinations of the different
versions, along with the script (or instructions) that produced them. That
way, the development system would "work straight from the box". All that
should be required is the newlib port of your specific hardware.
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to firstname.lastname@example.org
More information about the crossgcc