Re: Building gcc for an os less system

["Viswanathan Sankararam" <vishu27 at cox dot net>]

I tried building xscale-elf and it worked completely without giving any
errors. Only thing is when I run a simple hello world program the size of
the exe is about 2MB. When I use the preinstalled gnupro tools, its much
lesser. I have not yet tried yet what you have mentioned below.

Thanks a lot for your efforts and responses Kai and all the others.

-Vish


----- Original Message ----- 
From: "Kai Ruottu" <karuottu@mbnet.fi>
To: <vishu27@cox.net>
Cc: <crossgcc@sources.redhat.com>
Sent: Friday, October 31, 2003 3:52 AM
Subject: Re: Building gcc for an os less system


> <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
>


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com