Getting Closer

Mark Palmerino mbp@csr-bos.com
Sun Feb 25 17:10:00 GMT 2001


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



More information about the crossgcc mailing list