Re: Can't build gcc-3.0.1 for m68k-coff

[Larry Gray <larry at greenmotor dot com>]

>  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 
it?

>  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. 

Thanks,
Larry Gray
larry@greenmotor.com


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com