This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Questio about crosstool


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]