Very interesting. First pass gcc is still statically built btw.

Took some getting used to but I do like it. I assisted Pierre on testing it during changes. We both used it in pre-published form to build armv8 aarch64 for my Rock64 sbc. Old book was troublesome for arm use.

Try it out for your 64 bit arm sbc's peeps. Pretty sweet.

ding ding, I did it, using slackware as host, I think it was several steps into chapter 8(don't remember how far I got before I got a bunch of compile errors) and had to stop and fix the slackware host before continuing.

It depends how you like to do your builds. The developers recommend doing it in one fell swoop but I always preferred to do it in installments. If you're used to going in and out of chroot, you don't forget to do it.

I create a script in /root called setup-chroot, which mounts all the necessary filesystems and then runs the actual chroot command. Then I run it at the beginning of each session.

I do the same thing, what messed me up was when I got interrupted by the grandson and forgot where I was at in the process.

I assume ur talking about the errors that pop up while running the tests, and not in the summary. That's normal. I've had those in EVERY build, of EVERY version of the book, on every host distro I've built it on. System builds just fine. What's important is the summary at the end, which should show only expected failures (which I suspect they are but leave it to the GCC devs to scare the pants out of u when compiling the damn thing!)

No, these are real failures. They occur in the summary too. The point I was making is that in all my earlier LFS versions I got only the six expected failures. In this one I got all these unexpected ones too. But as they are clustered around two operations (and only one bit of the program), there are probably only two glitches that keep coming up. Anyway it caused no further problems.

Just started the new way of building it's a little awkward, and not as convienient as having all the temp tools in a single tools folder, but I can see why the devs have done it this way, seems a lot less faffing about adjusting the tool chain ( gcc/binutils ) which I would imagine will make it easier to maintain, I think as pointed out above the in and out of chroot may cause some noobs a problem, though like most who have built a number of LFS os's I use a sccript for chrooting which does all the virtual file system stuff.

One minor error is this line in '7.14. Cleaning up and Saving the Temporary System'Doesn't work it should beNotice the trailing slash.

Haven't started on the 'real' system yet I will report back.

When I do a test build, I never clean up. It's still in the newly released 10.1 which I will be trying out this weekend.
I actually use a chroot to start the build, if I find the time I will share how it works for those who had problems, this are usually not the ones posting here in this thread but the ones making new threads when they have errors spewing at them. Main advantage is that you can use this method to build a much older version of LFS (if you would want that).

I am doing lfs-10.1 using my old lfs-7.3 chroot with updated binutils, gcc and make. Also added libffi, expat and Python-3. I had an error when compiling pass2 of binutils-2.36.1 in the temp-tools and tried binutils 2.36 which gave me the same error (libcft). The book does mention something about it but I actually had a different error there. I did find some similar problems with libcft when using older glibc. The chroot I use is indeed old. I prefer to build with an old chroot because that way I can build older lfs-versions as well. Anyway, I settled for lfs-10.1 with binutils-2.35.1 and attr-2.4.47 because I wanted to get rid of the getaddr error (which was there with lfs-10.0 as well) although it got replaced with another harmless error when using attr-2.4.47. Gcc-10.2.0 had 17 unexpected error with g++, nothing that worries me but it is more then I had with lfs-10.0. I will finish up this weekend. So far nothing really exciting, a bit of an issue with binutils 2.36 and up.
I finished LFS-8.3 with gcc-8.4.0 and glibc-2.27 and you can try it here: https://drive.google.com/file/d/1Fq1...ew?usp=sharing
Only 2 unexpected errors for gcc reported .

Last time doing LFS was LFS-9.1.

Currently doing LFS-10.1. Seems, now LFS using new method.

First, I tried building LFS using OLD method.

In this case using LFS-9.1 books, but the packages version are LFS-10.1.
I completed tools, entering chroot, and do it until section 6.10. Adjusting the Toolchain
All the linkers work perfectly. So I stop the progress here.


Then, I tried building LFS using NEW method.
So far, I am on section 7.4. Entering the chroot Environment .
Yes, entering chroot perfectly.
I will continue tomorrow.


I did old method to get rid of curiosity.
Can the old method still be used? Yes, it can.

But, I love the new method of building LFS.

I tested the new method on lfs-9.X and figured it should work the other way around too, thank you for trying it. I also prefer the new way, makes it easier to add stuff like pkgtools and/or other packaging tools.

What about the new way is better? I started 10.0 and got pretty confused because of the changes, but I have an open mind. Can anyone enumerate the advantages about the new build process?

You can add anything you want from BLFS before you start the final system much easier. Bootstrapping a package manager for example without using ./configure --prefix=/tools.
They documented how to make a back-up of the tools. You no longer need to make adjustments after glibc. At first it was a bit weird but it is worth it.

Also you avoid all that tiresome pre-editing before you can build gcc (both times).

I preferred the old way because it seemed more logical to me: all the intermediate tools went into $LFS/tools and all the final packages into $LFS/usr. But I dare say people who never did it that way will find it intuitive that everything is installed in its final site, whether it's an intermediate or a final package.