Sun Feb 25 17:10:00 GMT 2001
>> m68k-coff-gcc -s rm_crt0.S
>> /usr/local/m68k-coff/bin/ld: cannot open rm_crt0.o: No such file or
> 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...
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
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
=8 -Dmc68000 -D__embedded__ -D__mc68000__ -D__embedded__ -D__mc68000
achine(mc68000) -Dmc68020 -D__mc68020__ -D__mc68020 hello.c
GNU CPP version 2.8.1 (68k, Motorola syntax)
#include "..." search starts here:
#include <...> search starts here:
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
/usr/local/m68k-coff/bin/ld -m m68kcoff -T
c -o hello -L/usr/local/lib/gcc-lib/m68k-coff/2.8.1/msoft-float
0005331.o -lgcc -lc -lbcc -lc -lgcc
/usr/local/m68k-coff/lib/msoft-float/libc.a(exit.o): In function `exit':
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':
.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
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to email@example.com
More information about the crossgcc