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