Re: Can't build gcc-2.95.3 with g++ for m68k-elf

[Wolfgang Fritz <wolfgang dot fritz at gmx dot net>]

Kai Ruottu schrieb:
> 
> Wolfgang Fritz wrote:
> >
> > Kai Ruottu schrieb:
> > >
> > > Peter Barada wrote:
> > > > make[2]: Entering directory `/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj-crap-g++-2.95.3/m68k-elf/build-gcc/m68k-elf/libiberty'
> > > > make[2]: *** No targets specified and no makefile found.  Stop.
> > >
> > >  Before the new 'xgcc' etc. can compile and link, the compiler must be put to > > work.
> > > Trying to compile and link a simple "Hello World" will help to see the problem.
> > > Options like '-v' and '-Wl,-verbose' on the 'xgcc' command line will show more
> > > things...
> > >
> > >  The 'm68k-coff/elf' don't have a default target board, so the 'specs' and maybe
> > > the linker script for the added default target board must be edited... The link,
> > > lib, endfile, startfile and libgcc specs must be edited to be sane... Then the
> > > 'compiler' should work and the 'libiberty'-configure can succeed...
> >
> > Is there any documentation available how to make a "running" m68k
> > compiler without manual action? I tried to find out from the sources how
> > to do it, but gcc sources / configuration scripts are too hard for me.
> 
>  No, but a short doc comes here:
> 
>  The 'gcc/configure' script ('gcc/config.gcc' in 3.x) has the host/target templates
> defining the used config files, additions to the generated 'gcc/Makefile' (host/target
> overrides, the 'x-' and 't-' files) etc. For the 'm68k-' cases (they are choices in a long
> 'case'-switch), probably the templates are named as 'm68k-*-coff | m68020-*-coff' and
> 'm68k-*-elf | m68020-*-elf'.
> 
>  Looking at the template one can see that the main config header ('tm_file') for 'm68k-elf'
> is 'gcc/config/m68k/m68020-elf.h' or something, there may be 'gcc/config/elfos.h' (generic
> defs for an ELF-target) etc. included before it and so on... During the build the
> '$build/gcc/tm.h' has these 'target config headers' listed/chained for inclusion....
> 
>  The same thing may be defined and then undefined/defined again many times in the
> config-headers chain, but the last one is the final...
> 
>  Those 'LINK_SPEC', 'LIB_SPEC', 'STARTFILE_SPEC', 'ENDFILE_SPEC' etc. in these
> config-headers define what will be put into the resulted 'specs' as default...
> 
>  So it wouldn't be a problem to put any of the newlib-supported target boards to
> be the default target in the FSF-sources, after learning the config mechanism and
> editing or adding the final definition for a spec. It may be necessary to #undef
> and #define again something, if this was defined last in some generic header for
> many targets and it is wrong for the specific target.
> 
>  Anyway here is the end of the 'gcc/config/m68k/m68020-elf.h' in my gcc-2.95.3
> sources:
> 
> ------------------------ clip --------------------------------
> #undef LIB_SPEC
> #define LIB_SPEC        ""
> 
> #undef LIBGCC_SPEC
> #define LIBGCC_SPEC     ""
> 
> #undef LINK_SPEC
> #define LINK_SPEC       ""
> 
> #undef  STARTFILE_SPEC
> #define STARTFILE_SPEC  "crtbegin.o%s"
> 
> #undef  ENDFILE_SPEC
> #define ENDFILE_SPEC    "crtend.o%s -T mvme162.ld%s"
> 
> /* end of m68020-elf.h */
> ------------------------ clip --------------------------------
> 
> > The problem hurts most if you start to build the cross toolchains from
> > scratch (building newlib-1.10.0 stops with the same error). I would like
> > to build a patch to the gcc sources so gcc builds for a "dummy" 68k
> > target or if you have your board support package already, to build a
> > libgloss for that target. As a start point for learning the build could
> > generate a working compiler for one of these VME boards in the 68k
> > libgloss directory.
> 
>  For the current 'm68020' CPU-default perhaps one of the VME-boards could be
> the default. They seem to have a big enough memory-space for C++ too...
> 
>  The 'cpu32' case may be problematic, the BCC-target hasn't enough memory,
> so those 'hello.cpp' tries using the 'bcc.ld' will lead into weird? (but
> very educating...) problems. So although the 'bcc.ld' could look like a nice
> candidate for a cpu32 target, it brings some problems...
> 
>  Ok, my thought is that the 'm68k-coff/elf' could be splitted to three CPU-
> variations, 'm68k-' for the m680?0, 'mcpu32-' for cpu32/m683?? and 'm5200-'
> for Coldfire and each of them having a suitable default target board.
> Adding new templates to configure/config.gcc isn't that hard and providing
> new 'cpu32-elf.h', and 'm5200-elf' etc. config files as the 'tm_file' using
> the 'm68020-elf.h' as the base, isn't either...
> 
>  The problem is to find a person who wants to struggle with getting these
> fixes included into the FSF-sources...
> 
> Regards, Kai

Thanks a lot Kai. I'll try to find some time this weekend to look into
this. Sounds complicated but interesting.

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

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