[Idea / Suggestion] Toolchain Recipe

[rubyFeedback]

Hey there GoboLinux folks,

This is more an idea or a suggestion. I'll explain what I mean with it.

Yesterday I finally succeeded (again) in compiling a LFS system. \o/
Although on a non-GoboLinux host system for now.

That is, the toolchain first (all that is necessary to compile from scratch); right now I
am at this step exactly:

https://www.linuxfromscratch.org/lfs/view/stable/chapter08/readline.html

for an external harddisc (contains the compiled things), but I am confident that I
can compile the rest as well, as GCC, Glibc, binutils and the linux kernel are kind
of the "core", so if these work, chances are very high the rest will compile well.
Anyway.

LFS recommends that a "cross compiler" toolchain is first created. This is
the step I sometimes struggle with. Today, or rather yesterday, I succeeded,
and now I am backing it up, calling the "tools" directory actually "toolchain",
and I also use the date when I compiled it, so I remember when this was last
updated, in dd.mm.yyyy format.

Would a standalone toolchain also be useful for GoboLinux? Specifically linux
kernel, glibc, gcc and binutils.

It could reside in a single entry under /Programs/, no matter the name; I named
it Toolchain but it could have any other name.

Would this be useful for anything?

I believe one benefit, or possible two, aka one being that we have an additional
compiler; the other one I'd think would be for upgrading e. g. glibc. Usually
when glibc is updated, the other programs have to be recompiled, in order to
match any API changes (I think, but I am not 100% certain).

Perhaps on GoboLinux this can be a bit different. I assume that statically compiled
programs may not need to be recompiled. I often compile e. g. sed, awk, grep,
and make statically, so that these don't break too easily. And I used busybox in
the past; supposedly toybox is a modern replacement for busybox. I haven't
tested it much yet.

The main idea behind this, though, is to try to have a robust toolchain for
GoboLinux in place, including being more easily able to update Glibc. Right
now GoboLinux Glibc version is at:

https://github.com/gobolinux/Recipes/tree/master/Glibc

Version 2.30. Last release of glibc (or at the least the developer who creates
the tarball releases of glibc; if I recall correctly this isn't done by Red Hat but
someone else) is now at 2.41.

Glibc may not necessarily have to be updated often, but I found that older
glibc sometimes may cause indirect problems - sometimes a few small-ish
bugs or some incompatibilities, so being able to more easily update the
glibc would be beneficial in the long run. And last but not least, so that people
don't think GoboLinux is ancient. :) (Back in the early days, even KDE worked on
GoboLinux; back then qt3 was easy to compile and a lot smaller than qt6, and
the KDE packages were only few, like 10 or 20; now it is quite a lot more work,
but I am tracking most of these packages, and I am quite confident that I can
compile them from source. I'll give this a try soon, first I need to finish LFS,
then I will go through BLFS. I also plan to re-publish my ruby scripts here
eventually, though I need to go through various problems and issues that
have accrued; the GoboLinux specific parts in my scripts I haven't updated in
a very long time, so I need to revisit that and also update the local documentation
I keep, which will take a bit longer, at the least some weeks.)

PS: This issue can be closed at any moment in time, it is more an idea or suggestion.
Perhaps we can revisit it at a later time again, after we updated the gobolinux
recipes.