This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more infromation.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Jeff Domogala wrote: > > I've been attempting to build a i686-pc-cygwin to mips64orion-elf cross > compiler with cygwin 1.1.4 installed. I have run into a series of issues > along the way, and I am still stuck at this point. > > I used binutils-2.10 and gcc-2.95.2 this time and use the same configuration > options (after wiping out the previous attempt of course). I built binutils > without a hitch and the build of gcc did not require the header file > modification. But, this time I got the following while building gcc: > make[2]: Entering directory > `/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty' > make[2]: *** No targets specified and no makefile found. Stop. > > Here is the contents of config.log from > `/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty': > > configure:1749: checking whether the C compiler > (/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95. > 2/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -g -O2 ) works The words 'C compiler' are wrong here, it really means 'toolset' or something more bigger than just the compiler, ie. the assembler, linker, startup-routine (crt0.o), C-library (libc.a), linker script etc. are checked before trying libiberty. So your GCC compiler (in the 'gcc' subdir) most probably works now, you can compile a C-file into assembly with it (-S), use the target 'as' to produce an object file, '.o' (-c) etc. But you cannot yet link without the startup-routine (crt0.o) and without proper C-libraries (lib*.a)... > configure:1765: > /cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2 > /gcc/ -B/gcc-mips/mips64orion-elf/bin/ -o conftest -g -O2 conftest.c 1>&5 > /gcc-mips/mips64orion-elf/bin/ld: cannot open crt0.o: No such file or > directory > > It looks like to me that I need crt0.o for ld to work correctly. So, how do > I create this file and does it have to be made for the host or the target? The startup-routine belongs into your C-libraries and is a part of the Cygnus newlib. The newlib includes some startups, either in the libgloss/mips (or in the newlib/libc/sys/mips) for the supported target boards. I refer to my another message about the 'Makefile.in' fixes, whether to build newlib at the same time with GCC, or to just pre-install the newlib ('target') headers, as the GCC-manual suggests, then build only GCC using 'make all-gcc' or something, install GCC and then build newlib separately, install it, fix the 'specs' for GCC (see later) so that one can link and produce a simple "Hello World" executable with GCC + newlib etc. And when everything seems to work, to let the 'GCC build' try the same before building libiberty & Co... Doing things one at a time and trying to understand what the separate tools really do while 'compiling', e.g. that the 'xgcc + cpp + cc1'-chain produces only assembly for 'as'. Trying the '-v' with the native GCC tells quite a lot about the 'compiling phases'. In order to produce GCC for the target, one needs only the target headers and the binutils for the target. Nothing more. For producing executables for the target one needs the target libs, including the startup-routine. So you will need the 'crt0.o' for the 'target' now or later. The first thing to understand is that you really need a real 'target'... While a 'mips-linux-gnu' involves a defined startup for Linux/MIPS, known system calls for Linux in its C-library etc., your 'mips64orion-elf' says only the CPU-type and the object format, not anything about the I/O-arrangement or 'opsys' in your target board. There aren't any 'defaults' for these things in the GCC config files... Ok, the 'specs'-file has the default options given to the linker, here is a clip from my 'specs' for 'mips64orion-elf' : --------------- clip ------------------------ *cc1plus: *endfile: crtend%O%s *link: %{G*} %{EB} %{EL} %{mips1} %{mips2} %{mips3} %{mips4} %{bestGnum} %{shared} %{non_shared} %(linker_endian_spec) -T pmon.ld%s *lib: -lc -lpmon -lc *libgcc: -lgcc *startfile: crtbegin%O%s crt0%O%s *switches_need_spaces: --------------- clip ------------------------ The freely available 'PMON'-monitor on the target board is my default for the 'opsys', so its linker script 'pmon.ld' and its glue library (for the low-level-I/O like 'read()', 'write()',...) are defined here. Ok, you will have the 'crt0.o' in 'gcc-mips/mips64orion-elf/lib' after building and installing first GCC, then newlib, and GCC will find it automatically (because already installed), but if you try the GCC and newlib at the same time, you haven't the probably needed -B/gcc-mips/mips64orion-elf/lib in the options given to 'xgcc', so the linker doesn't find it because of the new 'relative search paths' using the: $prefix/lib/gcc-lib/$target/$version/../../../../$target/lib instead of the straight path: $prefix/$target/lib > It is not addresses in the crossgcc FAQ. Did you RTFM at all before looking the FAQ ? "Installation/Cross-Compiler" in the GCC-manual (> 500 pages) really tells about the 'crt0.o', C-library for the target etc. The most common problem seems to be that people no more ask questions like "I have GCC but no manual for it, where the hell it is ?". I haven't seen this 'obvious' question asked for a while although all Linux distributions seem to miss the manual, Cygwin ?, Mingw ? ... The GCC-manual not belonging to a GCC- distribution ? Bullshit... (Perhaps the 'gcc.info' is included, but it should be history...) I prefer PDF, so e.g. the RedHat/Cygnus 'Embedded Development Toolkit' (EDK) at: ftp://ftp.redhat.com/pub/redhat/edk, and the PDF & HTML-manuals with it (although for 'gcc-2.9-99r1p1') can be suggested, until one builds his/hers own ones from the GCC-sources using Tex, Ghostscript, texi2html etc. Someone described the GCC-manual production process on this list some months ago... I would consider this skill just as important as producing the toolset binaries. After the toolset build one should have the binaries and ALSO the docs for it... The Cross-GCC FAQ addressing the docs-building at all ? Hmmm, if I continue critizing the FAQ, not contributing anything to it (how I could when not agreeing with it?), soon I must write one myself (from all the answers I have written to this list...). The big problem is that I have my own NIH-like opinions about the things, not always agreeing with the FAQ... > One last thing... I was assuming that I did not need to build a native > toolchain with the non-cygnus tree before I built the cross compiler. Is > this a correct assumption? I read the entire crossgcc FAQ and did not see > an answer to this question. Of course you don't need it... 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] |