Ian Lance Taylor wrote :
Kai Ruottu <[EMAIL PROTECTED]> writes:
Ok, the traditional "evolutionary" method is to not reinvent the wheel
with the already tested target components but let then be as they are
and produce only the stuff required for the new $host, the GNU
binutils and the GCC sources. NOT the target C libraries because
they already are there for the existing targets! The Kegel's idealism
says that also all these MUST be built with the new GCC. The glibc,
the X11 libraries, the Gnome libraries, the KDE libraries, the termcap,
the ncurses,.... Horrible "bolshevism/bullshitism" I would say....
What in the world are you talking about?
Some stupid typos like 'then' instead of 'them', 'sources' appearing
after 'GCC',
could have caused you to write this, but I don't think it being the case...
crosstool is a one stop shop for people who don't want to figure out
how everything fits together. Given that, it clearly must build the
target libraries. It can't assume that they already exist.
This has no typos I think, but despite ot that it sounds like asking
that "if the sun
is a star, why we don't see it among the other stars at night"? Quite
clear question
but very hard to answer...
So what in the world are you then talking about? That everyone should
rebuild the
target glibc already having its runtimes already installed on the target
system? That
those "installed runtimes" really don't exist there? One sees them
there but what one
sees isn't really true? Everyone can see the sun go around the earth
but that isn't the
case? When everyone knows how a star looks like and that stars can be
seen only at
night, the sun cannot be a star when it is so big and it really cannot
be seen at night?
Maybe I'm stupid when for instance seeing a glibc for Linux/PPC in many
Linux distros
and I really believe it working as the "target C library" when producing
a crosstoolchain
for any Linux/PPC :-(
For which existing targets the prebuilt C libraries are missing? Or
which are the
targets which don't have any "suitable", "compatible" or something C library
which could serve as that temporary bootstrap "target C library" during
the GCC
build? In those "special optimized for something" toolchain cases...
I'm sorry crosstool doesn't fit your philosophical notions (which are,
moreover, incorrect as stated). If you have something substantive to
say about crosstool--like, say, it doesn't work, or doesn't do what
people want--then say that.
Ok, crosstool doesn't work and it doesn't do what the ignorant people
think it
doing!
The cases are many where it has no sanity, but lets take two very
common from
the "embedded Linux" world for which "crosstool" was made :
1. remote debugging - the libs on the cross-host and the target must be
identical
2. Java - for some totally unclear reason mixing a self-made 'libgcj.so'
with existing
installed C and C++ runtimes doesn't work. Not even in cases where
both the
installed system and the crosstoolchain have used totally identical
sources, the
libraries for the cross-host only being prebuilt on some other
system than the
libraries on the installed system.
Generally the case is about producing a crosstoolchain for an existing
Linux system,
and the goal is to produce apps for this system, not replace it with
something totally
self-built. And in these cases the replacement of the target libraries
with self-built
ones is not recommended by me. Others may disagree but I have the right
to tell
my own....
