none none wrote:
So what you are suggesting is to give up crosstools
and try build my own tool chain using the lib path of
my embedded system.
Taking the target C library from the target system is the assumption. For
the proprietary targets there are no sources for the C library available,
the GNU C library only (really) supports Linux and the newlib only the
embedded (no native GCCs for them) targets. Even that Linux support
means 'generic' Linux, every distro provides its own 'custom' glibc. Or
at least everyone should be prepared to this being the case...
Could I copy the *.so files that
my /lib dir contains on my embedded system and use
them while I make, make install the binutils, gcc on
my host machine?
Yes, providing the target C library for the GCC build is obligatory in the
'system' target (which can have native GCCs) cases! The 'final GCC'
stage in those 'from scratch' methods uses the self-built one during the
GCC build but normally the first GCC build is the final build....
Can anyone suggest documentation or a
how to for this as I have found only for bootstraping
and building everything (binutils,gcc,glibc) from
scratch.
This is unfortunate... The gcc-2.95.3 manual used to tell the basics in
crosscompiler builds but not so well, for instance using the default
$prefix,
'/usr/local' there, not $prefix taken from '--prefix=$prefix'....
The new '--with-sysroot=$sysroot' was aimed to help people to copy
those weird native install schemes onto the cross-host, using that $sysroot
as the install root for the copied stuff. So one only needs to invent a
suitable 'sysroot' and copy the C library there. For instance:
/opt/host-$target
where $target is the target name, for instance 'arm-debian-linux-3.0'
for the
"Debian 3.0 release for ARM"....
Pre-gcc-3.3.3 ones must be built via somehow fitting the target C library
into '$prefix/$target', into '*include' (two pcs!) and 'lib' there....
Building binutils shouldn't need anything for the target being installed
unless
the new '--with-sysroot=' then checks that there really is
something..... The
GCC build then checks the target headers for fixing and checks the target
C library for available functions in it!
Moreover my /lib dir on the target system has very few
libraries and it seems to have been built using
egcs-2.91.66- does this put any restrictions on which
gcc/binutils should I use? In /lib dir there is
libc-1.99.so (libc.so.6 is a symbolic link to it) as
the glibc shared library.
Sounds being a 'pre-2.0' glibc.... Let's hope you will find the headers and
the startups for it ! Then producing older GCCs like 2.95.3 and even to 3.4
should work easily....
(I have not set up the system in the first place but took it ready with linux
on it)
Generally the sources and all the produced binaries for them should be
available and being delivered to the customer....
