Re: Getting Closer

[Joel <joel_schantz at yahoo dot com>]

I had a problem years ago with the "stock" libraries that are built.
I had a 68000 system that I was compiling for, but unfortunately the standard libs are compiled for
68020.
This causes no end of grief for a 68000.
So I ended up modifying m68k-none for TARGET_CPU_DEFAULT and MULTILIB_DEFAULTS
and t-m68kbare for MULTILIB_*  to suit me.
then regenerated my cross compiler.

This may not be your problem (I think 68332 supports all 68020 instructions), but It would simplify
things as well as eliminating all of those unused multilib combinations.

--	joel


Mark Palmerino wrote:
> 
> Hi all,
> 
> Kai writes:
> 
> >> m68k-coff-gcc -s rm_crt0.S
> >> /usr/local/m68k-coff/bin/ld: cannot open rm_crt0.o: No such file or
> >> directory
> >
> > The '-s' means 'strip the executable', while the '-S' means 'compile into
> > assembly'... In this case the '-c', 'compile into object' would have been
> > the right option. Getting and reading the GCC-manual is recommended...
> 
> Oh, ok, :-(, I got mixed up in the use of my flags.  There was a time when I
> knew the differences, but the mind is the first thing to go, they say...
> 
> The following:
> 
> m68k-coff-gcc -mcpu32 -c rm_crt0.S
> 
> produces a rm_crt0.o file. This rm_crt0.o file is the exact same length as
> the rm_crt0.o file that comes from the Windows system. Much of it is exactly
> the same. In fact, only 3 characters differ at characters 4, 6 and 7.
> Though, I don't know if this is close enough.  I'll try bringing this new .o
> file over to windows and see if it produces code that works...
> 
> In the meantime:
> 
> >> So, I thought, well there is the .o file that exists under windows, perhaps
> >> that will work. So I brought it over and put it in the directory that I'm
> >> working in and issued the following command:
> >>
> >> m68k-coff-gcc -oformat=srec -o hello hello.c
> >>
> >> and this produced an S-record file.
> >
> > But was it CPU32-code ?  Using the '-mno-bitfield -msoft-float' could be
> > quite the same as the '-m68332'. The '-m68020' is the default, so:
> >
> > m68k-coff-gcc -mno-bitfield -msoft-float -oformat=srec -o hello hello.c
> 
> Well, I don't know if it was CPU32-code.  In fact, I *thought* I was able to
> use the -m68332 flag more successfully than I seem to be able to now...
> 
> The gcc command Kai suggests produces:
> 
> # m68k-coff-gcc -mnobitfield -msoft-float -oformat=srec -o hello hello.c
> 
> 
> m68k-coff-gcc -m68020 -mnobitfield -msoft-float -oformat=srec -o hello
> hello.c -v
> Reading specs from /usr/local/lib/gcc-lib/m68k-coff/2.8.1/specs
> gcc version 2.8.1
>  /usr/local/lib/gcc-lib/m68k-coff/2.8.1/cpp -lang-c -v -undef -D__GNUC__=2
> -D__GNUC_MINOR__
> =8 -Dmc68000 -D__embedded__ -D__mc68000__ -D__embedded__ -D__mc68000
> -Asystem(embedded) -Am
> achine(mc68000) -Dmc68020 -D__mc68020__ -D__mc68020 hello.c
> /var/tmp/cc000533.i
> GNU CPP version 2.8.1 (68k, Motorola syntax)
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/lib/gcc-lib/m68k-coff/2.8.1/include
>  /usr/local/m68k-coff/include
> End of search list.
>  /usr/local/lib/gcc-lib/m68k-coff/2.8.1/cc1 /var/tmp/cc000533.i -quiet
> -dumpbase hello.c -m
> 68020 -mnobitfield -msoft-float -version -o /var/tmp/cc000533.s
> GNU C version 2.8.1 (m68k-coff) compiled by GNU C version 2.8.1.
>  /usr/local/m68k-coff/bin/as -mno-68881 -m68020 -o /var/tmp/cc0005331.o
> /var/tmp/cc000533.s
>  /usr/local/m68k-coff/bin/ld -m m68kcoff -T
> /usr/local/m68k-coff/lib/rm_rom.ld -oformat=sre
> c -o hello -L/usr/local/lib/gcc-lib/m68k-coff/2.8.1/msoft-float
> -L/usr/local/lib/gcc-lib/m6
> 8k-coff/2.8.1 -L/usr/local/m68k-coff/lib/msoft-float
> -L/usr/local/m68k-coff/lib /var/tmp/cc
> 0005331.o -lgcc -lc -lbcc -lc -lgcc
> /usr/local/m68k-coff/lib/msoft-float/libc.a(exit.o): In function `exit':
> /h/crossgcc/build-newlib/m68k-coff/msoft-float/newlib/libc/stdlib/../../../.
> ./../../newlib-
> 1.8.2/newlib/libc/stdlib/exit.c:70: undefined reference to `_exit'
> /usr/local/m68k-coff/lib/msoft-float/libc.a(sbrkr.o): In function `_sbrk_r':
> /h/crossgcc/build-newlib/m68k-coff/msoft-float/newlib/libc/reent/../../../..
> /../../newlib-1
> .8.2/newlib/libc/reent/sbrkr.c:61: undefined reference to `sbrk'
> 
> ...and so on with a number of functions.
> 
> I fear I still don't have my cross-compiler and associated directories set
> up right. Does the above tell you anything?
> 
> I wonder if I should start all over and generate the system for just the
> 68332 as you (Kai) suggested in a previous email.
> 
> Do you think that is warranted? If so, your suggestion was to edit the
> config/m68k/m68k-none.h file in a certain way (which is contained in that
> email) and also edit out of the gcc Makefile the MULTILIB* defines.
> 
> Is this correct?
> 
> If correct, I assume I would rebuild gcc and then newlib.  Since I had to
> build binutils before either gcc or newlib, I'm guessing I don't have to
> rebuild that - is that correct?
> 
> Then, I guess, I've got to delete a number of directories that resulted from
> previous builds...
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.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