Planning for Cross-LFS/Multi-Architecture 7.x Release
randy at linuxfromscratch.org
Mon Apr 18 21:33:41 PDT 2005
Jeremy Utley wrote these words on 04/18/05 23:14 CST:
> Randy McMurchy wrote:
>>Please, Jim, for me and I'm sure there are others that want to know
>>the same thing, can you explain *in a technical manner* how the
>>toolchain could be any "cleaner"?
> A simple example will document this clearly. Take building LFS on a
> Fedora core release. In the past, we had issues with our chapter 5
> glibc build picking up the presence of SE-Linux in Fedora core 3, which
> caused the chapter 5 glibc to also enable SE-Linux. But, once we got
> into chapter 6, it caused the glibc build to barf, because the headers
> for selinux were no longer present. This build process completely
> eliminates that situation. Anything that links to the host does NOT end
> up at all in the $LFS tree - the 2 packages which are linked to the host
> (cross-gcc and cross-binutils) are prefixed to the build user's home
Thanks for the input, Jeremy. Though I still don't understand how
this relates to my question.
My question is about the finished binaries. In the example you give
above, it doesn't have anything to do with the finished product. It
only has to do with failures *getting* to the final product.
I realize that the process as Jim outlined eliminates problem hosts.
But what about for hosts that can build without issues?
The need to reboot and build from the console is an overwhelmingly
big new difference. To the point that I would have to find a different
build method than what Jim described.
I have build scripts, but I don't run them. I cut and paste them. I
wish to examine the output of each command before continuing the build.
Especially with new versions of LFS. Sure it takes me a bit longer
to do it this way, but everything is checked out as I go along. I
don't have to go back and figure out what caused something to fail
along the way because of a problem 6 packages ago.
I'm just asking questions because it seems to be a huge new difference
in the build method. Nothing of which benefits me. Sure this sounds
as if I'm disappointed that LFS doesn't cater to my needs, but our
current build method works well, for the large majority of readers.
Shouldn't we continue to cater to the large majority. I liked Jeremy H's
idea about a split in the book when it comes time to reboot or chroot.
Shouldn't we investigate to see if something like this is feasible.
That's all I'm asking.
rmlscsi: [GNU ld version 188.8.131.52.2 20041220] [gcc (GCC) 3.4.3]
[GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686]
23:21:00 up 16 days, 22:54, 3 users, load average: 0.09, 0.11, 0.09
More information about the lfs-dev