1

Both LFS and CLFS apply patches to the GCC source before building.

The CLFS patches are a bit more involved than the LFS patches, but what they have in common is the changing of the path used to find the dynamic linker. In this case its moved to the location where a new version of glibc is going to be built.

Since, at least in the case of CLFS, you are building a cross toolchain and presumably you cannot run anything built with this chain on your build machine, what difference does it make where GCC has programs look for the dynamic linker. Isn't that a runtime operation which is never going to happen anyway? Also, if you built a binary with this GCC, one which required shared libraries, and attempted to run it on your target wouldn't the path to the dyanmic linker now be wrong?

Additionally (C)LFS has you modify the STANDARD_STARTFILE_PREFIX_X to point to $INSTALL_PATH/tools/lib/. Wouldn't those paths presumably be checked when/if you specifiy --with-sysroot? After building GCC with --with-sysroot if I check --preint-search-dirs I don't see it looking in any paths besides ones referenced to either prefix or --with-sysroot.

Improve this question
1
  • One fix to this post: early in the (C)LFS process they have you symlink ${INSTALL_PATH}/tools to /tools. When you apply the patch to GCC to change the linker path you apply it to use /tools, which is the prefix you are going to use when building glibc. Since you build the temporary filesystem in ${INSTALL_PATH} (which contains the tools directory) when you chroot to ${INSTALL_PATH} the dyanmic linker is magically the same path as it was on your build machine. – Jay Dec 15 '16 at 21:39
2

The pages that you have linked are for constructing a temporary tool chain which is then used to construct the final system in Chapter 6 of LFS. The GCC in Chapter 6 is compiled without any patches. The patches in the temporary tool chain are only there to allow further compilation of packages independent of what tools the host system is using.

Improve this answer
3
  • Perhaps I have a deeper misunderstanding then. I assumed that the patch in question changes the path to the dynamic linker. I assumed that the dynamic linker is only used at runtime. And lastly I assumed that none of the binaries built with the cross toolchain would be exectuted by the build machine, which is the only machine on which the modified dynamic linker path will exist. I don't know if all of that is true, but if it is then I don't understand why we would apply the patch at all. – Jay Dec 15 '16 at 13:17
  • Yes, the patch in question changes the location to where a temporary dynamic linker is created. However, until the final system is ready and booted up, everything is being executed on the host machine CPU. So, to make sure that applications from the host machine are not involved in the final build, a bootstrapping process is necessary. The first part of LFS (CH 5) is constructing a temporary tool chain to bootstrap the final system in Ch 6. All the tools that are output in /tools directory are for bootstrapping. CLFS is a bit more complicated, and AFAIK not maintained anymore. – Munir Dec 15 '16 at 17:36
  • Once you reach Ch 6 of the book, you enter a chroot environment which isolates you from the host. The only tools available within this chroot are the ones built in /tools. This is the actual construction of the LFS. See linuxfromscratch.org/lfs/view/stable/chapter01/how.html page of the book for details. – Munir Dec 15 '16 at 17:40
0

(C)LFS tries very hard to build a linux system with as little ties to the build machine as possible. As a result some of the steps can seem unnecessary, redundant, or contrived. Here is (a subset of) the CLFS process which addresses the primary question:

  1. Ch5: Cross binutils
  2. Ch5: 1st pass cross GCC
  3. Ch5: Glibc (which can be used by both a cross and target-native compiler), gets installed with prefix of /tools
  4. Ch5: 2nd pass cross gcc. The dynamic-linker-path-patch is applied here to point to /tools, which is a symlink to $CLFS/tools where $CLFS is the root of the target's file system.
  5. Ch6: Use the 2nd pass cross gcc to build a bunch of new tools which will be native to the target, these include a version of gcc to run native on the target. Conspicuously absent from this list is another copy of glibc. This isn't required because the one built earlier is fine for now.
  6. Ch10: Boot/chroot into the target system, which now has /tools in the same place as your build machine. This allows tools built (as native) earlier to access the dynamic linker. Now you will make glibc over again but this time it will go into the standard /usr (instead of /tools/usr)

The root of the question had to do with the dynamic linker path, and the fact that it appears relative to the build machine. The answer is basically that the OP (me) wasn't thinking about how there was a symlink between /tools and ${CLFS}/tools and that the patch was applied to make /tools the root path to the linker.

I have no answer for the STANDARD_STARTFILE_PREFIX_X question.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.