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