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. 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. 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. 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? --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
