This is the mail archive of the
mailing list for the GCC project.
Re: Unclear documentation on building GCC together with binutils
On 11/29/06, Brian Dessent <firstname.lastname@example.org> wrote:
Normal? After producing much more than 1000 cross-toolchains this doesn't
It can be a lot more convenient. For example, for a cross-toolchain,
the normal procedure would be:
adjust PATH to make just-installed files available
move to another build dir
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
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-
I would call these ideas as "bolshevism" or "bullshitism" because there
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."
truth in them, only some blind believe to some weird ideas... For
someone tells that there are no prebuilt C libraries for Linux/PPC,
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,
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
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
much harder than in the SCO UnixWare 7.1.4 case I tried recently... Why
Linux is more "closed" than SCO Unix?
It could be interesting to do research on the misunderstandings people
about the target libraries... For all sanity one could assume people
that these are like PDF files in documents, one just copies them from a
another and don't need to "customize" them for the new host... But some
really rebuild them for each new host and if the result on the new host
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
(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
being "suitable" if not "right" for some demanding user... But even
would prefer to drive with some "suitable" tyres to the shop where to
"right" tyres instead of driving there with a "stripped car", with bare
because nothing else than the right tyres would be accepted... With Linux C
libraries the situation is quite the same, one either accepts
a "suitable" Linux C library or then not.
In 1994 after buying a box with Linux install media and when trying to
it into an empty PC which had no opsys on it, it was really frustrating
out that installing Linux required one to first purchase MS-DOS! Or ask
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...
old PCs cannot boot from the new Linux CDs, fortunately there are things
"Smart Boot Manager" and if one has that on a floppy, installing Linux
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...