On 12/04/2019 12:37, DJ Lucas via lfs-dev wrote:
On March 28, 2019 7:00:29 PM CDT, Ken Moffat via lfs-dev
<[email protected]> wrote:
It is disappointing that glibc links to static libgcc. What we
really need is a new generation of experimenters to replace Greg and
Ryan.
I like the sound of the "very clean method", but I'm not sure that
it helps, particularly if someone uses an archived old version of
tools. But on the other hand, it is possible that I saw actions
like that getting mentioned because of problems which resulted, so
perhaps anyone doing that will get to keep both the pieces.
Ken, thank you for making mention of this. An interesting way to wake, maybe
even a tiny bit disturbing, but I've been doing LFS for a really long time. :-)
Just a fleeting idea after waking at 4:00 AM, that I've obviously no time to
explore, but wanted to get it out there in case somebody would like to explore.
Anyway, why not make a real chroot environment? We can still use /tools for the
first environment, so it's not that drastic of a change, we just populate it
via DESTDIR installs, built for the host with our modified temporary vendor
field. We'd chroot into it just like we do now, and do the same (with adjusted
triplet) for our real new root up to the point that we have the tools needed on
the real new root to proceed with the native build, then exit our tools chroot
environment, and chroot into the target.
Thanks for mentioning that: I've tried that before becoming involved in
jhalfs (and then in blfs). One of the problems I had at the time (around
2010) was that not all packages in chapter 5 are cross-compile friendly,
so they needed hacks. It may be better today. But as you say, it
eliminates a lot of the tweaks we have to do right now.
Off the top of my head, chapter five might grow a bit, but we'll eliminate the
separation of libstdc++ and the double build of gcc.
Whatever you do, the minimum number of builds is two: one to build a
cross-compiler, and one using the cross-compiler to build a native one.
But maybe the rebuild of gcc in chapter 6 wouldn't be needed, although a
good bootstrapping procedure would require a third one, which compares
well with the second one.
I'm not sure for libraries (when I was doing that, gcc was written in
pure C), but the problem is that building libstdc++ (cross-compiled)
needs a cross-compiled glibc, which can itself only be built after
building the cross-compiler... So separating libstdc++ might still be
necessary.
We'd likely have to tighten up the host requirements a bit too. What we gain is
real paths throughout the build, a more mainline build method (but also less
hacks to the build machinery), a build method that more readily mimics what
distros do, and we get to introduce a useful implementation of DESTDIR for a
fair number of packages (yes it'd still be repetitive). It also makes the work
that went into Greg, and later, Ken's comparison builds much easier by being
able to do comparisons easily at any point we choose (per package), and it
gives us the opportunity to reinvent the book a bit. For that last point, I'm
envisioning introducing tough topics as they are needed, rather than being
locked away in an earlier chapter where they might be overlooked.
Comparison does not work anymore because of some randomization in code
generation... Maybe, It could be disabled by some switch, though. We may
look at what is done for comparing the second and third build of gcc at
the end of a bootstrap.
I'm sure there are lots of holes in the above being that I woke with it, but
thought I'd throw it out there anyway. I think that ticks off all of the boxes
identified in the earlier thread without introducing more exotic flags, or even
existing hacks we currently use for the toolchain. Thoughts?
It is certainly worth trying, but who will be able to find the time for
doing this? I'm working steadily towards a complete jhalfs automated
LFS/BLFS (some kind of reference build), trying not to ask my fellow
editors to modify their habits, and it takes almost all my free time.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
