Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#2461 closed task (fixed)

Minor changes needed in Toolchain Technical Notes

Reported by: chris@… Owned by: Matthew Burgess
Priority: normal Milestone: 6.5
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

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.

Attachments (4)

toolchain.patch (4.2 KB ) - added by Matthew Burgess 15 years ago.
toolchain-v2.patch (3.7 KB ) - added by Matthew Burgess 15 years ago.
toolchain.2.patch (6.0 KB ) - added by bdubbs@… 15 years ago.
Another variation of the changes.
toolchain-3.patch (6.4 KB ) - added by chris@… 15 years ago.
Another variation

Download all attachments as: .zip

Change History (15)

by Matthew Burgess, 15 years ago

Attachment: toolchain.patch added

comment:1 by Matthew Burgess, 15 years ago

Owner: changed from lfs-book@… to Matthew Burgess
Status: newassigned

Chris,

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

Matt.

comment:2 by Matthew Burgess, 15 years ago

Milestone: 6.5

by Matthew Burgess, 15 years ago

Attachment: toolchain-v2.patch added

by bdubbs@…, 15 years ago

Attachment: toolchain.2.patch added

Another variation of the changes.

comment:3 by bdubbs@…, 15 years ago

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.

comment:4 by Matthew Burgess, 15 years ago

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

comment:5 by chris@…, 15 years ago

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.

by chris@…, 15 years ago

Attachment: toolchain-3.patch added

Another variation

comment:6 by Matthew Burgess, 15 years ago

Resolution: fixed
Status: assignedclosed

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.

comment:7 by bdubbs@…, 15 years ago

Resolution: fixed
Status: closedreopened

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 ...

comment:8 by Matthew Burgess, 15 years ago

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.

comment:9 by bdubbs@…, 15 years ago

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...

comment:10 by Matthew Burgess, 15 years ago

Resolution: fixed
Status: reopenedclosed

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

comment:11 by Matthew Burgess, 15 years ago

I meant r9026 and r9027 :(

Note: See TracTickets for help on using tickets.