18.3.2011 16:07, David Paterson kirjoitti:
On Fri, Mar 18, 2011 at 10:39 AM, David Paterson<dnpaterson@xxxxxxxxx> wrote:
It is, I agree, quite hard to understand. My attempts so far at
putting Newlib into the GCC directory haven't had much success :{
I'll keep trying...
I'm not having much success at all.
I've put the added the Newlib sources to the GCC source directory - an
additional directory at the top level. I've created
$PREFIX/$TARGET/sys-include and copied the Newlib/newlib/libc/include
files, and the $PREFIX/include files into it (it wouldn't build
without the latter for some reason - I tihnk if sys-include is there
the other include directories are ignored).
What on earth '$prefix/include' headers?
You seemed to have used the '--with-sysroot=$sysroot' which means
"making a cross GCC which behaves like a native GCC for the $target".
Usually people make fully normal cross GCCs for embedded targets,
because these don't have any native GCCs to mimic, to put the native
headers and libraries into a $sysroot which follows the native install
scheme and serves as an image for the native target system...
A normal cross GCC uses :
$prefix/bin - for the human-usable executables working on the
cross $host
$prefix/$target/bin - for the GCC-usable binutils executables
$prefix/$target/include - for the target headers
$prefix/$target/lib - for the target libraries
$prefix/libexec/gcc/$target/$gcc-version - for the GCC-version
dependent executables
$prefix/lib/gcc/$target/$gcc-version - for the GCC-version dependent
libraries
after its installation. And that :
$prefix/$target/sys-include
is required during the GCC build to have the target headers. The
'$prefix/$target/bin' and '$prefix/bin' should have the target
binutils for GCC and for the build script (the "human user" in this
case, the produced GCC doesn't use the '$target-<tool>'s in any way)
So whatever the reason was to add the '--with-sysroot=$sysroot' to
point to the "native target stuff", please forget it and don't use
this configure option at all! Using it doesn't belong to producing
the "cross only" toolchains for embedded targets !
With system targets like Linux, Unix etc. it has a quite motivated
use to get a cross GCC to mimic a native GCC and get all the native
directories in use with the cross GCC. For instance Solaris has its
libraries in :
/usr/ccs/lib
/usr/lib
/usr/ucblib
and so on, there isn't only one 'lib' but many of them which all
should be got in use... An embedded target (newlib) needs only
one 'lib', the optional variations (multilibs) are in subdirs of
it...
I can get GCC to build OK, but Newlib is just ignored. I thought the
configure and make commands were set up to go recursively down the
tree, processing any "configure" and "Makefile" entries they found,
but that doesn't seem to happen. I've tried to figure out what I need
to do to build Newlib, but have to admit I'm more than a little
baffled by the intricacies of the configure and make systems.
As was told, just provide the 'newlib' and 'libgloss' subdirs in the
main GCC source dir, for instance as 'gcc-4.5.2/newlib' and
'gcc-4.5.2/libgloss' and then they should be built just like
the 'libiberty', 'libstdc++-v3' and 'libssp' for the target with the
built 'xgcc', 'cc1' etc.
Maybe all this is too simple to understand... When one expects things
being complicated then one tries to make them such, like using the
'--with-sysroot=$sysroot' for something which even shouldn't be there.
I myself see that "native system with a native GCC, native headers and
native libraries" quite imaginary for an embedded target...
