Andrew Haley wrote:
> The guy is building a cross compiler, not a native compiler.
And you believe that building system libraries from scratch is going
to be easier?
Probably the case is about a big misunderstanding like :
1. the target binutils will be made for the cross host
2. the target GCC will be made for the cross host
3. the target glibc will be made for the cross host (NOT only for the
$target as some dummies
could think :)
If the target glibc was produced with some other GCC version, this maybe
could cause some
compatability problems when linking those objects produced with the
cross GCC with the
ones in the glibc... One possible misunderstanding more. Nightstrike
could explain what kind
of misunderstandings he has and why the previous step 3 is seen being
necessary.
With native GCC builds I haven't seen many thinking that after updating
the GCC, also the
installed glibc and other target libraries should be updated or
recompiled with the newer GCC-
version (the results must be better!). Nightstrike could try this when
next time updating the
native GCC :)
Or behind all this there is some political idea like :
o all Linuces should be 100% binary compatible so generic Linux
headers and generic Linux
libraries can be used when producing apps for some Linux/CPU system
That there are those generic Firefoxes, Thunderbirds, OpenOffices
distributed in binary format
(but are there for the Linux/x86_64's?) quite easily hints this being
true... So nowadays Linux
should be "just like Windows", all apps distributed as binaries made by
generic "crosstool"-based
toolchains....
People will easily forget that there are also the X11 libraries, the
Gnome, the KDE, the ncurses,
the termcap and all kind of other target libraries. That glibc doesn't
cater that much... Producing
also all these would be a big job, copying and unpacking the originals
for the target is much
easier! With multi-targets the task can be more complicated, so
producing a separate cross-
toolchain for each distro can be the most easy way...
