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] |
Other format: | [Raw text] |
<vishu27@cox.net> wrote: > Im sorry Kai, actually i was builing for xscale-coff. I put the command > lines wrongly and got confused as I am trying to build both > xscale-coff and elf. I will let you know if xscale-elf builds. For pure curiousness I tried the xscale-coff target with gcc-3.3.1 and it could be built without any problems. I built it from scratch when not having a prebuilt newlib for xscale-coff, which you can have. Anyhow my build method is the simple 'traditional' one without any recently invented complications: 1. build binutils for the target using '--prefix=$prefix --target=$target' and install them 2. copy the newlib headers for the target into $prefix/$target/include, they are in 'newlib-1.11.0/newlib/libc/include' in the current newlib 3. set the symlinks to $prefix/$target/sys-include (those also Peter Barada told being required, ie. for the 'limits.h', 'stdlib.h' and 'unistd.h') 4. configure GCC using '--with-newlib' and build for both C and C++ 5. build newlib with the installed GCC 6. be happy So a GCC for a newlib-using target can be built when only the target headers are installed, and the resulted GCC is the final one. For most targets (with newlib) the generic newlib headers (step 2.) are the same as the final, but for ARM/XScale the 'newlib/libc/sys/arm/sys/param.h' should replace the generic 'sys/param.h', so two 'cp' commands may be required in step 2. Anyway no wacky 'bootstrap-GCC's and many build iterations... If you have prebuilt working newlibs for xscale-coff/elf, you can of course use them in your GCC-builds and first with the new produced GCCs until you are sure that the new GCCs will work as expected. And then update both newlibs from their sources... BTW, my 'xscale-coff' toolchain has only the steps 1-4 done now... Building newlib is obligatory but whether Insight/GDB/run must be a separate one, is unclear, targets like 'm68k-elf', 'h8300-elf', 'sh-elf' can have the equivalent '-coff' as a supported subset... Whether you will build from scratch or using old prebuilt C libraries during the GCC builds, all the (available) prebuilt target stuff must be installed in: $prefix/xscale-coff/bin (binutils) $prefix/xscale-coff/include (headers) $prefix/xscale-coff/lib (libraries) $prefix/xscale-coff/sys-include (the symlinked headers) in the 'xscale-coff' case, and in: $prefix/xscale-elf/bin (binutils) $prefix/xscale-elf/include (headers) $prefix/xscale-elf/lib (libraries) $prefix/xscale-elf/sys-include (the symlinked headers) in the 'xscale-elf' case, before starting to configure and build the GCCs. That the symlinks are required is clearly a bug, but how to get the GCC-developers to understand this is then another issue.... There are quite a lot 3rd party headers to describe I/O-port addresses etc. in different ARM/StrongARM/XScale chips, and putting these into the 'system-specific' header directory, separate from the 'standard' C headers (newlib ones), shows better organizing... As can be seen with the C preprocessor : ------------------------------------ clip ------------------------------------------------------------ /home1/kai > cpp-xscale-coff-3.3 -v Reading specs from /usr/local/lib/gcc-lib/xscale-coff/3.3.1/specs Thread model: single gcc version 3.3.1 (by karuottu@mbnet.fi) /usr/local/lib/gcc-lib/xscale-coff/3.3.1/cc1 -E -quiet -v -D__ARM_ARCH_5TE__ - D__XSCALE__ -D__semi__ - ignoring nonexistent directory "NONE/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/lib/gcc-lib/xscale-coff/3.3.1/include /usr/local/xscale-coff/sys-include /usr/local/xscale-coff/include End of search list. ------------------------------------ clip ------------------------------------------------------------ there are only these two places for the target headers... The '/usr/local/include' here is the common place for all GCCs and the 2nd is for the GCC-version (and target) dependent headers... BTW, getting both the C++ and C search directories visible is now (for some peculiar reason) harder than it was earlier: ------------------------------------ clip ------------------------------------------------------------ /home2/usr/local/lib/gcc-lib/xscale-coff/3.3.1 > ./cc1plus -v ignoring nonexistent directory "NONE/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include/c++/3.3.1 /usr/local/include/c++/3.3.1/xscale-coff /usr/local/include/c++/3.3.1/backward /usr/local/include /usr/local/lib/gcc-lib/xscale-coff/3.3.1/include /usr/local/xscale-coff/sys-include /usr/local/xscale-coff/include End of search list. ------------------------------------ clip ------------------------------------------------------------ I don't think the aim is that people should use 'cc1*' in order to see things like this... With gcc-3.2.x the 'cpp -Wp,-lang-c++ -v' still gave this same info... My tools have some local fixes like removing the ugly 'relative search paths' (with the '../../../../'), not showing what was done in configure, and enabling the common '/usr/local/include' Ok, both targets also should have their '$target-tool's (like 'xscale-coff-ar') in the '$prefix/bin', and this directory should be in the build system's PATH so that the '$target-tool's will be found when needed. The '$prefix' is the install prefix you want to use for all your GCCs and having a common 'standardized' prefix helps things. Companies have their own standards for this, for instance RedHat could be imagined to have used something like: /redhat/H-i686-redhat-linux/gnupro to tell the company who provides the tools, which is the host system and what are the tools... Some hosts may have their own standards like '/opt/<package>' with SVR4, for instance '/opt/gcc' for all the installed GCCs or '/opt/gnu' for all the installed GNU stuff, including GCCs... If one cannot think a suitable $prefix, there is always the default '/usr/local', which will be used if the '--prefix=$prefix' has been left away from the configures. Cheers, Kai ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |