Questio about crosstool

[Kai Ruottu]

Kristoffer Ericson kirjoitti:

> I'm almost finished with my native toolchain (and saved all the 
> configure, make, make install info), so just need to finish on more item 
> then i'll have a somewhat complete howto on how to make crosstool native.
> 
> Probobly have an update later tonight. About the libiberty issue, its 
> fixed by either one of two issues.
> 1. I've so far not have any success with adding other compiling 
> languages than c,c++. If you've set others try to just set those two.
> 2. Usually just run make & make install, not exactly sure about the 
> difference (between make & make bootstrap) but libiberty gets built. 
> Perhaps its needed to do "make, make bootstrap, make install"
> 
> GCC went alot smoother than for example Glibc so you shouldnt really 
> have much issues besides libiberty.

  Libiberty will normally be built only for the $host before going to the
'gcc' subdir to build GCC there. After that the libiberty for the 
$target will be built just as the libstdc++ for the $target. Generally
producing libiberty for the $build sounds vain, the native 'cc' in a
final GCC build could always be assumed to be GCC, not a proprietary
native 'cc' (like in Solaris, AIX, HP-UX,...), and therefore already
having libiberty built for it and being installed somewhere.... Anyway
when linking these 'gen*' executables which handle the machine 
description file ('config/$cpu/$cpu.md'), linking against libiberty will
be done and it must exist also for the $build compiler.

  Building the libiberty for the $build compiler of course should happen
before 'make' going to the 'gcc' subdir, but if this doesn't happen,
the simple fix is to write :

   make all-build-libiberty

or something, please see the resulted main 'Makefile', I remember the
make "target" being named as this... So writing this before going to
build GCC itself should work around this bug in GCC. I remember this
problem once becoming from using the 'canonical' $build system name
like 'i686-pc-linux-gnu' instead of the given 'alias' name like
'i686-linux-gnu', and no 'libiberty.a' found in the searched
'$build/i686-pc-linux-gnu/libiberty' because this didn't exist at all,
a '$build/i686-linux-gnu/libiberty' then existed...

  Generally I don't understand the "make, make bootstrap, make install"
mentioned here... The system which will run the resulted compiler, is
an alien system, totally different from the $build system. So one can
only make an 1:1 image for the "native GCC install" on the alien system,
sysrooted somewhere and using the suggested :

   make DESTDIR=path-to-rootdir install

(please see the GCC manual) when installing the alien binaries into
the $build system. One cannot just expect the binaries being 
automagically ftp'ed into the alien host and being installed into
it... Maybe if this "path-to-rootdir" is NFS-mounted to be seen in
the $host system...

  The usual newbie-mistakes like the produced 'specs' made by the
crosscompiler, not by the produced new native GCC of course must
be solved somehow... Usually manually running 'gcc -dumpspecs'
later on the native target system...

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com