This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]