public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
* Making progress, but...
@ 2001-02-19 14:44 Mark Palmerino
  2001-02-19 22:28 ` Kai Ruottu
  2001-04-01  0:00 ` Mark Palmerino
  0 siblings, 2 replies; 8+ messages in thread
From: Mark Palmerino @ 2001-02-19 14:44 UTC (permalink / raw)
  To: crossgcc

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!

However, I'm not sure they got installed in a way that I was expecting.

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.).

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

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'
/var/tmp/cc005792.s:9: Error: Unrecognized opcode: `jsr'
/var/tmp/cc005792.s:10: Error: Unrecognized opcode: `addq.l'
/var/tmp/cc005792.s:12: Error: Unrecognized opcode: `unlk'
/var/tmp/cc005792.s:13: Error: Unrecognized opcode: `rts'
gcc: file path prefix `/usr/lib/gcc-lib/m68k-coff/2.8.1/' never used

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
-D__embedded__ -D__mc68000__
-D__embedded__ -D__mc68000 -Asystem(embedded) -Amachine(mc68000)
-D__HAVE_68881__ -Dmc68020 -D
__mc68020 -D__mc68020__ hello.c /var/tmp/cc005847.i
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.
 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.

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

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

Thanks.




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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Making progress, but...
  2001-02-19 14:44 Making progress, but Mark Palmerino
@ 2001-02-19 22:28 ` Kai Ruottu
  2001-02-20  6:18   ` Mark Palmerino
  2001-04-01  0:00   ` Kai Ruottu
  2001-04-01  0:00 ` Mark Palmerino
  1 sibling, 2 replies; 8+ messages in thread
From: Kai Ruottu @ 2001-02-19 22:28 UTC (permalink / raw)
  To: Mark Palmerino; +Cc: crossgcc

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:

    ftp://sources.redhat.com/pub/newlib

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

> 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'
file...

> 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 ---------------------
*cc1plus:


*endfile:


*link:
-m m68kcoff -T bcc.ld%s

*lib:
-lc -lbcc -lc

*libgcc:
-lgcc

*startfile:


*switches_need_spaces:

------------------ 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, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Making progress, but...
  2001-02-19 22:28 ` Kai Ruottu
@ 2001-02-20  6:18   ` Mark Palmerino
  2001-02-21  2:05     ` Kai Ruottu
  2001-04-01  0:00     ` Mark Palmerino
  2001-04-01  0:00   ` Kai Ruottu
  1 sibling, 2 replies; 8+ messages in thread
From: Mark Palmerino @ 2001-02-20  6:18 UTC (permalink / raw)
  To: karuottu; +Cc: crossgcc

Hi all,

Thanks, Kai, for the suggestions.  Here is the result of one of your
suggestions:

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

Ok, here is what I get with the above command:

m68k-coff-gcc -print-search-dirs
install: /usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/
programs: 
/usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/:/usr/local/lib/gcc-lib/m68k-
unknown-coff/:/usr/lib/gcc/m68k-unknown-coff/2.8.1/:/usr/lib/gcc/m68
k-unknown-coff/:/usr/local/m68k-unknown-coff/bin/m68k-unknown-coff/2.8.1/:/u
sr/local/m68k-unknown-coff/bin/
libraries: 
/usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/:/usr/lib/gcc/m68k-unknown-co
ff/2.8.1/:/usr/local/m68k-unknown-coff/lib/m68k-unknown-coff/2.8.1/
:/usr/local/m68k-unknown-coff/lib/

It looks to me like the problem is that the program is looking for
"m68k-unknown-coff" rather than "m68k-coff" - am I reading the above
correctly?

If so, does this suggest a recompile? And, if so, why did
'--target=m68k-coff' get transformed into 'm68k-unknown-coff' and what
should I do about it?

I suppose an alternative is to rename all the 'm68k-coff' directories to
'm68k-unknown-coff', but this feels like a kludge to me.

Any suggestions?


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Making progress, but...
  2001-02-20  6:18   ` Mark Palmerino
@ 2001-02-21  2:05     ` Kai Ruottu
  2001-04-01  0:00       ` Kai Ruottu
  2001-04-01  0:00     ` Mark Palmerino
  1 sibling, 1 reply; 8+ messages in thread
From: Kai Ruottu @ 2001-02-21  2:05 UTC (permalink / raw)
  To: Mark Palmerino; +Cc: karuottu, crossgcc

Mark Palmerino wrote:
> 
> Thanks, Kai, for the suggestions.  Here is the result of one of your
> suggestions:

 You are welcome.

> > Why the 'm68k-coff-gcc' alone didn't work will be solved using the command
> >
> > m68k-coff-gcc -print-search-dirs
> >
> 
> Ok, here is what I get with the above command:
> 
> m68k-coff-gcc -print-search-dirs
> install: /usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/
> programs:
> /usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/
> <snip>
> /usr/local/m68k-unknown-coff/bin/
> libraries:
> /usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/
> <snip>
> /usr/local/m68k-unknown-coff/lib/
> 
> It looks to me like the problem is that the program is looking for
> "m68k-unknown-coff" rather than "m68k-coff" - am I reading the above
> correctly?

 Yes...

> If so, does this suggest a recompile? And, if so, why did
> '--target=m68k-coff' get transformed into 'm68k-unknown-coff' and what
> should I do about it?

 This seems to be some kind of bug. The $target in '--target=$target'
should appear as 'target_alias' in the resulted Makefile, not the 'full
name' generated by 'config.sub' or something. Anyway this bug hasn't
been seen in the recent GCCs...

 Ok, you can edit the Makefile, remove the '-unknown' from the 'target'
and 'target_alias' definitions, then remove the 'cccp.o', 'gcc.o', 'g++.o',
'*protoize.o', 'prefix.o' and 'toplev.o', I think these could be influenced
by the 'target_alias' or 'target' name. The 'make' and 'make install' again
and remove all the old installed 'm68k-unknown-coff' stuff...

 Weird is also that the 'm68k-coff-*' executables were with the right prefix,
not with the 'm68k-unknown-coff-*' names...

> I suppose an alternative is to rename all the 'm68k-coff' directories to
> 'm68k-unknown-coff', but this feels like a kludge to me.
> 
> Any suggestions?

 There are only two used, shown in the 'snipped' output from '-print-search-dirs',
and the binutils and newlib installs use only the second so perhaps just making
a symlink from the '/usr/local/m68k-coff to the '/usr/local/m68k-unknown-coff',
will solve the missing binutils, libs and headers problem. The binutils and newlib
installs used the right target name quite surely...

Cheers, Kai



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Making progress, but...
  2001-02-20  6:18   ` Mark Palmerino
  2001-02-21  2:05     ` Kai Ruottu
@ 2001-04-01  0:00     ` Mark Palmerino
  1 sibling, 0 replies; 8+ messages in thread
From: Mark Palmerino @ 2001-04-01  0:00 UTC (permalink / raw)
  To: karuottu; +Cc: crossgcc

Hi all,

Thanks, Kai, for the suggestions.  Here is the result of one of your
suggestions:

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

Ok, here is what I get with the above command:

m68k-coff-gcc -print-search-dirs
install: /usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/
programs: 
/usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/:/usr/local/lib/gcc-lib/m68k-
unknown-coff/:/usr/lib/gcc/m68k-unknown-coff/2.8.1/:/usr/lib/gcc/m68
k-unknown-coff/:/usr/local/m68k-unknown-coff/bin/m68k-unknown-coff/2.8.1/:/u
sr/local/m68k-unknown-coff/bin/
libraries: 
/usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/:/usr/lib/gcc/m68k-unknown-co
ff/2.8.1/:/usr/local/m68k-unknown-coff/lib/m68k-unknown-coff/2.8.1/
:/usr/local/m68k-unknown-coff/lib/

It looks to me like the problem is that the program is looking for
"m68k-unknown-coff" rather than "m68k-coff" - am I reading the above
correctly?

If so, does this suggest a recompile? And, if so, why did
'--target=m68k-coff' get transformed into 'm68k-unknown-coff' and what
should I do about it?

I suppose an alternative is to rename all the 'm68k-coff' directories to
'm68k-unknown-coff', but this feels like a kludge to me.

Any suggestions?


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Making progress, but...
  2001-02-19 14:44 Making progress, but Mark Palmerino
  2001-02-19 22:28 ` Kai Ruottu
@ 2001-04-01  0:00 ` Mark Palmerino
  1 sibling, 0 replies; 8+ messages in thread
From: Mark Palmerino @ 2001-04-01  0:00 UTC (permalink / raw)
  To: crossgcc

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!

However, I'm not sure they got installed in a way that I was expecting.

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.).

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

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'
/var/tmp/cc005792.s:9: Error: Unrecognized opcode: `jsr'
/var/tmp/cc005792.s:10: Error: Unrecognized opcode: `addq.l'
/var/tmp/cc005792.s:12: Error: Unrecognized opcode: `unlk'
/var/tmp/cc005792.s:13: Error: Unrecognized opcode: `rts'
gcc: file path prefix `/usr/lib/gcc-lib/m68k-coff/2.8.1/' never used

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
-D__embedded__ -D__mc68000__
-D__embedded__ -D__mc68000 -Asystem(embedded) -Amachine(mc68000)
-D__HAVE_68881__ -Dmc68020 -D
__mc68020 -D__mc68020__ hello.c /var/tmp/cc005847.i
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.
 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.

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

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

Thanks.




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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Making progress, but...
  2001-02-19 22:28 ` Kai Ruottu
  2001-02-20  6:18   ` Mark Palmerino
@ 2001-04-01  0:00   ` Kai Ruottu
  1 sibling, 0 replies; 8+ messages in thread
From: Kai Ruottu @ 2001-04-01  0:00 UTC (permalink / raw)
  To: Mark Palmerino; +Cc: crossgcc

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:

    ftp://sources.redhat.com/pub/newlib

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

> 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'
file...

> 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 ---------------------
*cc1plus:


*endfile:


*link:
-m m68kcoff -T bcc.ld%s

*lib:
-lc -lbcc -lc

*libgcc:
-lgcc

*startfile:


*switches_need_spaces:

------------------ 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, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Making progress, but...
  2001-02-21  2:05     ` Kai Ruottu
@ 2001-04-01  0:00       ` Kai Ruottu
  0 siblings, 0 replies; 8+ messages in thread
From: Kai Ruottu @ 2001-04-01  0:00 UTC (permalink / raw)
  To: Mark Palmerino; +Cc: karuottu, crossgcc

Mark Palmerino wrote:
> 
> Thanks, Kai, for the suggestions.  Here is the result of one of your
> suggestions:

 You are welcome.

> > Why the 'm68k-coff-gcc' alone didn't work will be solved using the command
> >
> > m68k-coff-gcc -print-search-dirs
> >
> 
> Ok, here is what I get with the above command:
> 
> m68k-coff-gcc -print-search-dirs
> install: /usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/
> programs:
> /usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/
> <snip>
> /usr/local/m68k-unknown-coff/bin/
> libraries:
> /usr/local/lib/gcc-lib/m68k-unknown-coff/2.8.1/
> <snip>
> /usr/local/m68k-unknown-coff/lib/
> 
> It looks to me like the problem is that the program is looking for
> "m68k-unknown-coff" rather than "m68k-coff" - am I reading the above
> correctly?

 Yes...

> If so, does this suggest a recompile? And, if so, why did
> '--target=m68k-coff' get transformed into 'm68k-unknown-coff' and what
> should I do about it?

 This seems to be some kind of bug. The $target in '--target=$target'
should appear as 'target_alias' in the resulted Makefile, not the 'full
name' generated by 'config.sub' or something. Anyway this bug hasn't
been seen in the recent GCCs...

 Ok, you can edit the Makefile, remove the '-unknown' from the 'target'
and 'target_alias' definitions, then remove the 'cccp.o', 'gcc.o', 'g++.o',
'*protoize.o', 'prefix.o' and 'toplev.o', I think these could be influenced
by the 'target_alias' or 'target' name. The 'make' and 'make install' again
and remove all the old installed 'm68k-unknown-coff' stuff...

 Weird is also that the 'm68k-coff-*' executables were with the right prefix,
not with the 'm68k-unknown-coff-*' names...

> I suppose an alternative is to rename all the 'm68k-coff' directories to
> 'm68k-unknown-coff', but this feels like a kludge to me.
> 
> Any suggestions?

 There are only two used, shown in the 'snipped' output from '-print-search-dirs',
and the binutils and newlib installs use only the second so perhaps just making
a symlink from the '/usr/local/m68k-coff to the '/usr/local/m68k-unknown-coff',
will solve the missing binutils, libs and headers problem. The binutils and newlib
installs used the right target name quite surely...

Cheers, Kai



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2001-04-01  0:00 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-02-19 14:44 Making progress, but Mark Palmerino
2001-02-19 22:28 ` Kai Ruottu
2001-02-20  6:18   ` Mark Palmerino
2001-02-21  2:05     ` Kai Ruottu
2001-04-01  0:00       ` Kai Ruottu
2001-04-01  0:00     ` Mark Palmerino
2001-04-01  0:00   ` Kai Ruottu
2001-04-01  0:00 ` Mark Palmerino

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).