On 11/29/06, Brian Dessent <brian@xxxxxxxxxxx> wrote:
It can be a lot more convenient. For example, for a cross-toolchain,
the normal procedure would be:
configure cross-binutils
build cross-binutils
install cross-binutils
adjust PATH to make just-installed files available
move to another build dir
configure cross-gcc
build cross-gcc
install cross-gcc
Normal? After producing much more than 1000 cross-toolchains this doesn't
look in any way "normal". It looks being the situation where a newbie makes
ones first crosstoolchain and not being the situation where the builder
updates
ones cross-toolchain by rebuilding one of its components from newer bugfixed
sources.... I would see the latter case much more common among the cross-
toolchain builders.
This especially true for targets where you'd don't have easy access to
existing libc headers, as there is a chicken-and-egg problem of "can't
build a fully functional gcc without libc headers" and "can't build libc
without a functional gcc."
I would call these ideas as "bolshevism" or "bullshitism" because there
is no
truth in them, only some blind believe to some weird ideas... For
instance if
someone tells that there are no prebuilt C libraries for Linux/PPC,
Linux/ARM,
Linux/MIPS, Linux/SH, Linux/Sparc, Linux/m32r, Linux/am33, Linux/m68k,
quite many really believe although some 'dissident' would give the URLs from
where to download these... The prebuilt Linux libs are like UFOs,
people may
see them but they don't believe that they see them because so many tell that
they really don't exist....
I myself have never had any trouble in finding these libs... Besides
of course
with AIX, HP-UX, Apple's MacOS X etc. "closed" proprietary systems. And
with something like RHEL it is quite hard to find its original prebuilt
C libraries,
much harder than in the SCO UnixWare 7.1.4 case I tried recently... Why
RedHat
Linux is more "closed" than SCO Unix?
It could be interesting to do research on the misunderstandings people
have
about the target libraries... For all sanity one could assume people
to understand
that these are like PDF files in documents, one just copies them from a
host to
another and don't need to "customize" them for the new host... But some
people
really rebuild them for each new host and if the result on the new host
is different
from the existing, no bells are ringing in the builders heads... Of
course using a
different GCC to compile produces a different result but when using
"identical"
(made from the same sources) GCCs on different hosts, what they produce
should generally be identical....
Or when needing tyres for a car, one can choose among Michelins, GoodYears,
Continentals, Nokians (yes, Nokia was once famous for its very good rubber
boots and car tyres made for arctic environment!), Firestones etc. All
these
being "suitable" if not "right" for some demanding user... But even
this user
would prefer to drive with some "suitable" tyres to the shop where to
find the
"right" tyres instead of driving there with a "stripped car", with bare
wheels
because nothing else than the right tyres would be accepted... With Linux C
libraries the situation is quite the same, one either accepts
bootstraping with
a "suitable" Linux C library or then not.
In 1994 after buying a box with Linux install media and when trying to
install
it into an empty PC which had no opsys on it, it was really frustrating
to find
out that installing Linux required one to first purchase MS-DOS! Or ask
some
friend to make the boot floppies while laughing at that stupid Linux which
doesn't even have boot floppies for it... Nowadays PCs can boot from CDs
and don't require one to purchase a MS opsys earlier, but not then...
But still
old PCs cannot boot from the new Linux CDs, fortunately there are things
like
"Smart Boot Manager" and if one has that on a floppy, installing Linux
succeeds...
Ok, my point was to say that one should be prepared to some misappointments
and to use some "bootstrap" stuff sometimes, life will be much easier if one
accepts this fact...
