Minor changes needed in Toolchain Technical Notes

[chris@…]

A few parts of page 5.2 are outdated thanks to the change in the build method. One of the main issues is Pass 1 of GCC and Binutils involves cross-compiling them, so they are now installed not as "ld" or "gcc", but as /tools/bin/$LFS_TGT-[program]. The main issue this causes with the text is when it discusses building Glibc, and talks about how the various tools are found, and says:

"The compiler is generally not an issue since Glibc will always use the gcc found in a PATH directory."

This no longer applies since /tools/bin/gcc does not yet exist at that point. Also, the sample output from GCC's configure is slightly incorrect, as the target triplet (and by extension the subdir in /tools that binutils creates) is modified. Here's what I get:

checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld

Similarly...

"After the run of configure, check the contents of the config.make file in the glibc-build directory for all important details. Note the use of CC="gcc -B/tools/bin/" to control which binary tools are used and the use of the -nostdinc and -isystem flags to control the compiler's include search path."

Of course the references to -nostdinc and -isystem are still accurate, but the "gcc -B/tools/bin/" no longer appears there. I have:

CC = i686-lfs-linux-gnu-gcc

Finally, the description of the toolchain adjustment mentions installing a new linker, but that is no longer done - only the specs file is changed.

I'm not quite sure exactly how all of this information should be changed. For instance, the reference to "gcc -B/tools/bin/" (the important part of course being the "-B/tools/bin/") is used specifically as an example of how Glibc does not use toolchain defaults, but that is not used with the cross-compiler.

[Matthew Burgess]

Chris,

Thanks for the ideas. Could you take a look at the proposed patch please? I think it addresses all of your points.

Matt.

[bdubbs@…]

Another variation of the changes.

[bdubbs@…]

I made some changes and added an alternative patch.

Some wording was changed to make things clearer, but it is essentially saying the same things as the other patches.

[Matthew Burgess]

Thanks Bruce. I'll commit toolchain.2.patch this evening.

[chris@…]

I don't really understand the change from "environment that can be chrooted into" to "via the chroot command." The actual chroot command is not done until Chapter 6 - Chapter 5 is about creating the temporary build environment that will later be chrooted into, so the original text there sounds right.

And I just saw one more issue...right after the change to gcc's specs file is described, it says:

"As mentioned above, a hard-wired path to a dynamic linker is embedded into every Executable and Link Format (ELF)-shared executable."

Far as I can tell, that is *not* mentioned above. The dynamic linker is described earlier on the page, but it is not explained that its path is embedded into every program.

[chris@…]

Another variation

[Matthew Burgess]

Thanks Chris. That looked good to me, so I just added a note about using LFS_TGT to force the cross-compilation as discussed earlier in lfs-dev.

Fixed in r9021 and r9022.

[bdubbs@…]

I still don't like the wording of the start of the 2nd paragraph:

The overall goal of Chapter 5 is to provide a temporary environment that can be chrooted into, where

I would prefer:

The overall goal of Chapter 5 is to provide a temporary environment that will be the targeted chroot environment where ...

[Matthew Burgess]

I don't particularly care for the duplicate use of 'environment' in your suggested wording :-)

How about:

The overall goal of Chapter 5 is to produce a temporary area that contains a known-good set of tools. By using chroot, the commands in the remaining chapters will be contained within that environment, ensuring a clean, trouble-free build of the target LFS system.

[bdubbs@…]

You're right -- too many environments. How about:

The overall goal of Chapter 5 is to produce a temporary area that contains a known-good set of tools that can be isolated from the host system. By using chroot, the commands in the remaining chapters will be contained within that environment, ensuring a clean, trouble-free build of the target LFS system.

We;re picking at nits now...

[Matthew Burgess]

I think we're finally there, thanks Bruce! Committed in r9027 and r9028.

[Matthew Burgess]

I meant r9026 and r9027 :(