This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |