Re: Building gcc for an os less system

["Kai Ruottu" <karuottu at mbnet dot fi>]

<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