Making progress, but...

Kai Ruottu
Mon Feb 19 22:28:00 GMT 2001

Mark Palmerino wrote:
> Hi all,
> I *think* I have successfully compiled and installed cross-dev versions of
> binutils and gcc for m68k-coff.
> First question, what do I need to compile to use stdio.h? Any pointers to
> that would be great!

 It comes with the C-library, normally newlib, please see:

The docs go with the name "GNUPro Libraries" in the RedHat GNUPro document

> When I built both of these I specified '--target=m68k-coff' but did not
> specify any prefix. I think, then, things got put into /usr locations (e.g.,
> /usr/local/bin, /usr/local/include etc.).

 The default value for '--prefix=....' is '/usr/local' and the GCC manual uses
it almost everywhere, not using the $prefix in the instructions...

> However, I'm curious about how I should be able to use gcc now that this has
> been done.  I guess I thought I could do the following:
> gcc -bm68k-coff -c hello.c

 Use simply the 'm68k-coff-gcc'... The use of 'gcc' comes from saving disk
space, being not able to remember the exact name or something. Anyway this
isn't common, every target normally has its own '$target-gcc' driver...

> and get a compile, but this doesn't work, instead I get:
> gcc -bm68k-coff -c hello.c
> /var/tmp/cc005792.s: Assembler messages:
> /var/tmp/cc005792.s:5: Error: Unknown pseudo-op:  `.even'
> /var/tmp/cc005792.s:8: Error: Unrecognized opcode: `link.w'

 The native 'as' was found first, not the 'm68k-coff-as' with its base name
in '/usr/local/m68k-coff/bin'...

> Also, if I try the following (with /usr/local/bin in my path),
> m68k-coff-gcc -v -c hello.c
> I get the this:
> Using builtin specs.
> gcc version 2.8.1
>  cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -Dmc68000

 It finds your native 'cpp' first, and couldn't even find the 'specs'

> GNU CPP version 2.8.1
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/macppc/include
>  /usr/local/include
>  /usr/include
> End of search list.

 These are the search paths for your native 'cpp'...

>  cc1 /var/tmp/cc005847.i -quiet -dumpbase hello.c -version -o
> /var/tmp/cc005847.s
> m68k-coff-gcc: installation problem, cannot exec `cc1': No such file or
> directory
> So, it didn't find cc1.

 Yes, it also finds your native 'cc1' first, not the 'm68k-coff' one...
> If I do the following:
> m68k-coff-gcc -bm68k-coff -v -c hello.c
> I get:
> 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) -Amachine
> (mc68000) -D__HAVE_68881__ -Dmc68020 -D__mc68020 -D__mc68020__ hello.c
> /var/tmp/cc005851.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.
> hello.c:1: stdio.h: No such file or directory

 Why the 'm68k-coff-gcc' alone didn't work will be solved using the command

    m68k-coff-gcc -print-search-dirs

> So, this looks like I need to compile and install whatever puts stdio.h into
> place - what would that be?

 Every target basically needs its own C headers and C libraries. Perhaps it is
possible to do some compile things (like compiling a C-library ;-) without a
C-library, but normally it will be needed...

 In the 'm68k-coff' case the 'libc.a' produced from the newlib sources isn't
'complete' but misses the low-level I/O and memory handling stuff. The 'embed'
document in the GNUPro docs should tell about what to do, but while experimenting
and building the extra libs for GCC any of the 'glue libraries' (having the
missing routines for some target board) coming with newlib will be suitable.
Editing a 'default target' (board) into the 'specs' file can be one way while
doing first tests. For instance :

------------------ clip ---------------------


-m m68kcoff -T bcc.ld%s

-lc -lbcc -lc




------------------ clip ---------------------

sets the 'BCC'-board being the default. The 'startfile' is told in the
used linker script, 'bcc.ld', so it is not told here. Putting it into
'specs' causes it being linked twice which causes errors...

 Please note the rigid syntax with the spec-name, spec-definition and
an empty line, ie. three lines for a spec. No less, no more...

 BTW, the '-lc' appears twice because 'libbcc.a' routines may need still
something from 'libc.a', also the 'libgcc.a' will be scanned twice, so
the link command will have '-lgcc -lc -lbcc -lc -lgcc'. Please see this
using the '-v' option while compiling & linking your 'Hello World'....

Cheers, Kai

Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list