0

I followed the LFS's insturctions and all of it seems to work properly yet. But i got confused when it comes to the second time of installation of the glibc after entering the chroot environment. My question is:

There is a glibc already compiled when building the cross-toolchain, and i assume all the codes inside that glibc should run on the lfs machine since the build process is configured with the parameter "--host=$LFS_TGT", if my assumption is right, then why do i need to build the glibc in the chroot environment again?

Here are the configure instructions used when building both glibc.

#compiling the cross-toolchain

../configure                             \
      --prefix=/usr                      \
      --host=$LFS_TGT                    \
      --build=$(../scripts/config.guess) \
      --enable-kernel=3.2                \
      --with-headers=$LFS/usr/include    \
      libc_cv_slibdir=/lib

#in the chroot environment

../configure --prefix=/usr                            \
             --disable-werror                         \
             --enable-kernel=3.2                      \
             --enable-stack-protector=strong          \
             --with-headers=/usr/include              \
             libc_cv_slibdir=/lib

Thank you!

juicyliberty
  • 35
  • 6
  • Have you read [ii. Toolchain Technical Notes](http://www.linuxfromscratch.org/lfs/view/10.0/partintro/toolchaintechnotes.html) chapter? Also related SO question (if not a duplicate): [why multiple passes for building Linux From Scratch (LFS)?](https://stackoverflow.com/q/39883865/673852) – Ruslan Sep 19 '20 at 14:29
  • @Ruslan yes i did, but still cant have a grasp of what is going on, and i think that post is refering "bootstraping the gcc", is that going to affect glibc? – juicyliberty Sep 19 '20 at 14:53
  • "Bootstrapping GCC" should actually refer to "bootstrapping the build system". These components—gcc, glibc, binutils—work together, and it would make little sense to bootstrap only one of them. See the second answer in the link I gave, if you haven't yet. – Ruslan Sep 19 '20 at 14:57
  • @Ruslan i'm not sure if i understand correctly, but isnt glibc going to be linked by the other programs? how does glibc have any reference to the host's libraries. – juicyliberty Sep 19 '20 at 15:16
  • Yes it doesn't have any references to the host's libraries, but it does contain the traces of the host compiler: any consequences of its bugs, optimization behavior etc.. If you then later try to troubleshoot the final system, you'll have to reference the host system, with its particular versions of the packages at the time of building. If you instead do bootstrapping, and build your final system with the bootstrapped toolchain, then you at least have a known state: XYZ versions of toolchain that built XYZ (i.e. same) versions of the final system. – Ruslan Sep 19 '20 at 15:25
  • @Ruslan Thanks for the details sir, very informative! one more question :P, is bootstraping done manually, or all those stages are done automatically when compiling gcc in one pass? if it is done manually, then what is --disable-bootstrap used for? – juicyliberty Sep 19 '20 at 15:42
  • `--disable-bootstrap` option is used to bootstrap GCC only. It's the automatic process of ensuring that GCC can build itself (see [the docs](https://gcc.gnu.org/install/configure.html)). The bootstrapping done in LFS involves the whole toolchain. In chapter 8 there's little point in checking that GCC can build itself after it builds the first stage: our cross-toolchain is _already_ the same version of GCC. See also [Building GCC: What are the advantages and disadvantages of bootstrap?](https://stackoverflow.com/q/37473532/673852) – Ruslan Sep 19 '20 at 15:52
  • @Ruslan Really appreciated! These have been a real pain for days. Thank you for such patience! – juicyliberty Sep 19 '20 at 16:11

0 Answers0