Jay wrote:
> From: meissner
> a) Configure binutils with --prefix=.
> b) Build and install bintuils.
>
> c) Configure gcc with --prefix= --with-as=/bin/-as
> --with-ld=/bin/-ld. Build, and compiler fails in
> libgcc. Go into the gcc directory and do make install.
>
> d) Put /bin and /bin on your PATH.
>
> e) Configure newlib with --prefix=. Build and install.
>
> f) Go back to the binutils build directory, reconfigure adding
> --with-sysroot=. Build and install.
>
> g) Go back to the gcc build directory, reconfigure adding
> --with-sysroot=. Hopefully at this time, the build and
> install should succeed.
Michael, Thank you for spelling this out clearly.
But isn't this one of the things a merged tree is supposed to handle "automatically"?
ie: substituting one bit of work for slightly different work?
During the 10+ years I have built crosstoolchains there has always been
new prophets and gurus who have invented "a wonderful new much more
complicated way" to produce them :(
The simple rules have though always been :
1. producing GCC requires at least headers for the target, this is
enough only for the newlib-using target cases which will be
configured using the "--with-newlib". These targets don't know
such thing as "native GCC" for them and the cross-GCC is the
default GCC type for them. For those targets which have the
native-GCC as the default type for them, one should also provide
the target C library binaries, startups and library files because
configuring the "extra" libraries: 'libiberty', 'libstdc++',...
will make link tests in order to see what the target C library has
and has not. The target headers are required in the 'fixinc' phase,
in order to see what headers the target has and has not. For instance
the target's own 'limits.h' will be checked for existence and the
GCC's 'limits.h' will be fixed to '#include_next' it if it exists.
2. Copying the generic newlib headers shouldn't be any rocket science
although it sometimes seems being :( Maybe the GCC instructions
should teach how people can use the 'cp' or 'copy' command. The
headers are in 'newlib/libc/include' in the newlib-x.y.z sources
so copying them from one 'include' onto another 'include' shouldn't
be that hard.
3. Also the target binutils should be available/installed BEFORE one
could configure and build GCC
4. Both binutils and GCC should be configured with just the same
'--prefix=$prefix' and '--target=$target' values!
5. The install place is the '$tooldir' aka '$prefix/$target'. After
configure & build & install the subdirs 'bin', 'include' and 'lib'
will keep the stuff which GCC itself will use. Human beings shouldn't
need to use anything there directly! (But in a from-scratch/bootstrap
situation the target headers should be copied there)
6. The directory '$prefix/bin' will keep the human-usable
'$target-<tool>' tools/utilities like 'mips-elf-gcc', 'mips-elf-g++',
'mips-elf-as', 'mips-elf-nm',... if one used '--target=mips-elf' in
the binutils and GCC configures
7. Both the binutils and GCC builds should succeed nicely. Using
'--enable-languages=c,c++' in the GCC configure should be OK but
trying languages like Ada and Java for an embedded target may be
"unexpected" and not work :(
8. After one has binutils and GCC ready (installed), one can use them
to compile newlib.
There however have been BUGS in the GCC sources :( Sometimes configuring
new extra libraries like 'libssp' (or something) has tried some link
tests although the '--with-newlib' should have replaced the tests with
pre-made answers for existence/non-existence of fuctions in newlib. Then
there has been that "eternal bug" (since 1995!) called as "sys-include
bug" - for some totally insane reason the target headers are expected to
be seen in the '$prefix/$target/sys-include' during the cross-GCC build!
This directory is the equivalent to the native SYSTEM_INCLUDE_DIR, a
directory for "additional" system-specific headers some target systems
may have, not only the standard headers in 'STANDARD_INCLUDE_DIR',
usually '/usr/include'. During a native-GCC build there has never been
any equal, checking headers from '/usr/sys-include' and totally
neglecting the '/usr/include' ones for instance.... Ok, maybe still with
gcc-4.3.x people must provide the target standard headers in
'$prefix/$target/include' to be seen also in
'$prefix/$target/sys-include' during the GCC build :(
The '$sysroot' in '--with-sysroot=' is the place where to put the
target's (native)headers in a usual 'system target' case, a target which
already has its native-GCC and the cross-GCC is another incarnation of
it on another "cross host" system.... Like when one wants to produce
things for SuSE Linux 10.2/PPC when having only a SuSE Linux 10.2/x86_64
or a SuSE Linux 10.2/i686 development platform... Or wants to produce
stuff for Sparc/Solaris10 on one's own Linux/x86... Imaging what kind of
"native platform" hosts the native-GCC for a target like 'mips-elf', can
require very vivid imagination :( Although quite many people have
claimed me to have that kind of imagination, still my logic cancels the
thought about using '--with-sysroot=' with some embedded target which
doesn't have and never has had that 'native stuff' to be installed into
that '$sysroot'...
Ok, some targets like Sparc/Solaris2.x have many 'include' and 'lib'
directories, even Linux has its '/lib', '/usr/lib' and '/usr/include',
not even mentioning those '/usr/X11R6/include' and '/usr/X11R6/lib'
for the X11 stuff. So the traditional '$prefix/$target/include' and
'$prefix/$target/lib' weren't enough for those 'system targets' and
the '--with-sysroot=' was invented to fix this problem. But still the
traditional '$prefix/$target' or '$tooldir' is enough for the newlib-
using embedded targets!
Like:
cd /src
mkdir gcc
cd gcc
mkdir gmp
mkdir mpfr
# binutils first, so that gcc overrides it
tar --strip-components=1 -xf ../binutils-2.18.tar.gz
tar --strip-components=1 -xf ../gcc-4.3.2.tar.gz
cd gmp
tar --strip-components=1 -xf ../../gmp-version.tar.gz
cd ../mpfr
tar --strip-components=1 -xf ../../mpfr-version.tar.gz
mkdir /obj
cd /obj
/src/gcc/configure ...
make
make install
???
(--strip-components is missing in most versions of tar, so I need to write that otherwise..but for now I require recent GNU tar).
> --with-ld=/bin/-ld. Build, and compiler fails in
> libgcc. Go into the gcc directory and do make install.
Better to configure -disable-libgcc? Like so that you can just expect success?
Or, if one is automating this, when ignoring the error, ensure that gcc/xgcc exists?
Or even just do like "make all-gcc" or such?
> g) Go back to the gcc build directory, reconfigure adding
The preexisting build directories should be deleted entirely, right?
Or does this work well incrementally?
A few times by accident I've seen configure error whenever rerun with a different command line.
The prefix in cases be omitted and the default /usr/local used?
I think I saw a warning to install into a directory to which you have not previous installed. Seems a bit onerous on the user, but also onerous to implement otherwise -- you don't know what files to delete that older/broken installed put there.
Thanks,
- Jay
