Trying to figure out what host to use

[Mark Palmerino]

Hi Kai et. al.,

Many thanks to everyone who is responding with helpful hints and ideas for
helping me!  

Naturally, I have some more questions, and I'm hoping you will bear with me:

> Yes, the target is right, but you must check that the 'libgcc.a' for '-m68332'
> or '-mcpu32' will be generated. The 'libgcc.a' contains e.g. the basic
> soft-float routines ('fadd'/'fsub'/'fmul'/'fdiv', but not with these
> names...). The cpu32- core needs different routines than the default
> '-m68020'.  The 'config/m68k/t-m68kbare' should set the variations in the
> MULTILIB_OPTIONS...
> 

Ok, I'm still a bit hazy on the implications of the above.

Here are some lines from the Makefile in my build-gcc directory:

MULTILIB_OPTIONS = m68000/m68020/m5200 m68881/msoft-float
MULTILIB_DIRNAMES =
MULTILIB_MATCHES = m68000=mc68000 m68000=m68302 m68000=m68332 m68020=mc68020
m68020=m68040

MULTILIB_EXCEPTIONS = *m5200/*m68881 *m5200/*msoft-float

(Note, I tried to follow the directions from part 4 of the crossgcc FAQ. I
untarred the gcc source files into a directory, then made a build-gcc
directory from which I ran the configure as follows: ../gnu*/gcc/configure
--target=m68k-coff --prefix=/volume/FFS_500/bar)

So, I don't see a reference on MULTILIB_OPTIONS to either 68332 or cpu32.
But there is a reference to 68332 on the MULTILIB_MATCHES define. Is this
adequate/correct for doing what I want (ultimately to produce S-record files
for a 68332 chip???)

And, I've looked at 'config/m68k/t-m68kbare' and it has the same lines as
above. Should I modify anything, or is this correct?

>> Assembler messages:
>> Error: invalid switch -mc68020
>> make: *** [libgcc1-asm.a] Error 1
>> 
>> deletions...

> The "Assembler messages" says that the error was given by the assembler, 'as',
> not by the C-compiler. You will need to build and install the GNU binutils for
> the same 'm68k-coff' target first. And must use the same '--prefix=...' and
> '--target=...' as when configuring GCC.  The
> "/volume/FFS_500/bar/m68k-coff/bin/ar"
> tells that you used the
> 
> --prefix=/volume/FFS_500/bar --target=m68k-coff
> 
> when configuring ($prefix/$target/bin is the place for the binutils), and it
> tries to use the 'm68k-coff'-targeted archiver, 'ar', when adding stuff into
> the 'libgcc.a'...

I did build binutils 2.9.1 before I attempted to build gcc.  As far as I can
tell, that worked - with a little coaxing as described below.  I also
followed the instructions in the FAQ, created a build-binutils directory and
issued the following from this build directory:

../binutils-2.9.1/configure --target=m68k-coff --prefix=/volume/FFS_500/bar

When this was done, I did the following:

make all install

and it chunked through and quit while working the Makefile in ./ld with the
following error:

make[1]: Leaving directory `/volume/FFS_500/tstuff/build-binutils/gas'
make[1]: Entering directory `/volume/FFS_500/tstuff/build-binutils/ld'
Makefile:232: *** commands commence before first target.  Stop.
make[1]: Leaving directory `/volume/FFS_500/tstuff/build-binutils/ld'
make: *** [all-ld] Error 2

Line 232 is in the middle of a long list of .o files beginning with:

ALL_EMULATIONS = 

Ok, the way I dealt with this error was to reduce that long list to a single
reference to em68kcoff.o and to modify another section of the Makefile which
had alot of dependencies to all the .o files in this emulation list to just
the following dependency:

em68kcoff.c: $(srcdir)/emulparams/m68kcoff.sh \
  $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/m68kcoff.sc \
     ${GEN_DEPENDS}
        ${GENSCRIPTS} m68kcoff "$(tdir_m68kcoff)"

I'm hoping this decision was correct because we are, after all, trying to
create code for a 68332, not others including MachTen running on a PPC.

Ok, with the above change, the compile continues successfully to a
completion. And the install puts things in the /volume/FFS_500/bar2
directory. 

What have I done wrong? Or, what could I have done more right?


> But starting with the gcc-2.8.1 sources and seeing if the '-mcpu32' support
> works in it is the easy start (after getting the binutils first).

So, I think I have binutils compiled and installed (let me know if it is
crippled given my edits).  I am working with gcc-2.8.1 at first, because I
am hopeful it will get me to a working system most quickly.

I have looked for "cpu32" in the 2.8.1 distribution, and don't see it. There
are references to cpu32bug in the newlib-1.8.2 distribution (which I haven't
worked with yet).



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