Compilation troubles

[Kai Ruottu]

Peter Coates kirjoitti:
> Good Morning,
>
> Recently I've been trying to set up a cross compiler for gcc using 
> version 2.95.3 supplied to me from a hardware vendor. The target is a 
> Samsung S3C2410,
This seems to be ARM920T  ("Thumb" mode supported)...

> and the host computer has been both a Windows XP (home and Pro) 
> machine running cygwin, and an SUSE Linux 10.1 machine.
>
> After following the vendor's instructions on installing the 
> toolchains, I have tried to run a simple "hello world" program on each 
> platform and every time I receive the error "unable to exec 'cpp0': no 
> such file or directory".

 The default place for this is '$prefix/lib/gcc-lib/$target/2.95.3' in 
the gcc-2.95.3 case...  The $target probably is 'arm-elf'
and the $prefix is something the GCC builder wanted it to be...
> I have used -print-search-dirs and find that the location where gcc 
> looks for its executables seems to be the same place where cpp0 is 
> located, except for the '/opt/' at the start of the path name - I 
> assume this might be a gcc method of defining the root directory?

 The previously told default place is usually the first one seen with 
the '-print-search-dirs' for "programs", so it should be
found!  If the install instructions ordered to change the built-in 
$prefix, then there should be something to compensate
that like setting a new "search root" in environment with 
GCC_EXEC_PREFIX...  The '-print-search-dirs' shows the
influence of this...  You should elaborate this "except for"!  Are the 
executables 'cc1*', 'cpp0' and 'collect2' installed into
a place which isn't seen among the shown search directories?

 If you haven't any sane reason to change the built-in install $prefix, 
don't change it whatever the install instructions will
tell!

> Searching the internet I found some other people having the same 
> problem, and it seemed to suggest that it was due to an incorrect 
> installation, although considering I did not build it in the first 
> place, it came from the vendor themselves,  and the fact it has failed 
> twice on seperate platforms seems to suggest otherwise. Another fault 
> may lie in the manufacturer's installation instructions, but this idea 
> seems suspect also.
 When one has a free choice to select this $prefix and then try to make 
it  a "standard" afterwards, each GCC provider
tries to 'push' its own 'standard' :-(  But  it would be better to use 
some suggested one!  For Cygwin hosted GCCs this
should be the '/cygwin', on Linux there unfortunately isn't anything 
(suitable, the one used for the native GCC, '/usr',
is too "limited for the system components"),  so choices like 
'/usr/local', '/opt/gnu', '/opt/gcc', '/opt/crossgcc'  etc. can
be seen... Some vendors could like to have their own 'brand name' and 
the 'host name' there like in :
'/opt/company-foo/H-i686-linux'....  Anyway the purpose is that  this 
'standard' would be used. The problem arises when
one must install another GCC from another vendor and wants it to use the 
same standard $prefix with the first one...
> Lastly, I have considered building a new platform from scratch using a 
> recent version of GCC, but I might not have the compilation tools to 
> do this currently, and I would much prefer a solution which might fix 
> my current GCC installation.
 Just try Google with 'arm-elf crosstool' and you should find many ARM 
tools...  The site:

     http://www.macraigor.com/full_gnu.htm

is one I remember...  Building oneself is ok if one doesn't need any 
handholding from others.  Learning the basics about
crosstoolchains happens best when using a crosstoolchain!

The gcc-2.95.3 still required separate compilers for the 32-bit ARM mode 
('arm-elf') and 16-bit Thumb mode ('thumb-elf')
but the gcc-3.4.x in the Macgraigor toolchain has both supported in one 
compiler, compiling for Thumb happens using the
'-mthumb' option for GCC...  Probably also gcc-4.x level tools are 
freely downloadable somewhere...