LFS & Yocto

1. configure script problem -> check the config.log file

2. Is it necessary to create a new partition when setting up the LFS project?
   Of course I could use an empty USB as the designated partition. But is it
   really necessary? Remember to create the swap partition when creating the
   designated partition for LFS.

3. We can first create a partition, then create a file system on the partition.
   This is the stardard method used in the LFS. However, as an alternative, we
   can first make a rootfs, then create an ext3 filesystem using the rootfs.
   The latter method is the default method used in OE/Yocto.
   That said, the key problem here is, how to create an ext3 filesystem from an
   existing rootfs? How does Yocto accomplish this task?
   Yocto uses 'genext2fs' tool to generate ext3 filesystem from rootfs.
   do_rootfs
    -> rootfs_rpm_do_rootfs
       rpm_preprocess_command
       install rpm packages into the rootfs
       rpm_postprocess_command
       rootfs_postprocess_command
    -> image_preprocess_command
    -> image cmd (genext2fs)
    -> image_postprocess_command

4. swap partition problem
   No swap partition on my ubuntu system here.
   Does it bring substantial benefits?
   [Principle: If not sure whether it's necessary or not, do not use it.]

5. Packages and Patches
   [compare the packages and patches with those in Yocto]
   *) the tools directory in LFS is like the native directory in Yocto

6. After downloading the tarball of a package, it's necessary to check the
   checksum of the tarball to make sure the packages is correct.

7. I'm not sure why 'ln -sv $LFS/tools /' is necessary.
   Explanation from official document:
   The created symlink enables the toolchain to be compiled so that it always
   refers to /tools, meaning that the compiler, assembler, and linker will work
   both in Chapter 5 (when we are still using some tools from the host) and in
   the next (when we are 「chrooted」 to the LFS partion).

8. create an unpriviledged user for a clean working environment
   groupadd lfs
   useradd -s /bin/bash -g lfs -m -k /dev/null lfs
   passwd lfs
   chown -v $LFS/tools
   chown -v $LFS/sources
   su - lfs

9. The difference between a login shell and a non-login shell (info bash)
   login shell
   *) interactive login shell
   *) non-interactive shell with --login option
   *) behavior
      *) it reads and executes /etc/profile if exists
      *) it looks for ~/.bash_profile, ~/.bash_login and ~/.profile, in that
         order and reads and executes the first one found
   non-login shell
   *) interactive non-login shell
      it reads and executes /etc/bash.bashrc and ~/.bashrc
   *) non-interactive non-login shell
      it first executes the following command before running the script
      if [ -n "$BASH_ENV" ]; then . $BASH_ENV; fi

10. Now that $LFS/tools and $LFS/sources are chowned to belong to lfs. What will
    happen if the USB is plugged onto another computer? Can the second computer
    be cheated to access the USB? I mean, if there's a user called lfs on the
    second computer, can the user access the $LFS/sources and $LFS/tools
    directory?
    YES!! Absolutely!!

11. setting up a clean environment
    cat > ~/.bash_profile << "EOF"
    exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
    EOF
    This ensures a clean working environment.
    cat > ~/.bashrc << "EOF"
    set +h
    umask 022
    LFS=/mnt/lfs
    LC_ALL=POSIX
    LFS_TGT=$(uname -m)-lfs-linux-gnu
    PATH=/tools/bin:/bin:/usr/bin
    export LFS LC_ALL LFS_TGT PATH
    EOF
    This turns off bash's hash function, so that it always searches the PATH
    when a program is to be run. As such, the shell will find the newly compiled
    tools in $LFS/tools as soon as they are available without remembering a
    previous version of the same program in a different location.

12. It's highly recommended to run test suites after packages are built,
    especially for the core toolchain packages, gcc, binutils and glibc.
    [The host system may exerts influence on the tests, causing inexplicalbe
    failures. This doesn't mean that the package is not compiled correctly.]
    [Sometimes package test suites will fail, but for reasons which the
    developers are aware of and have deemed non-critical.]
    OK, to conclude, don't run the test suites, as it's not worth the efforts.

13. concepts
    the final system
    the temporary minimal system
    host-independent toolchain

14. binutils
    binutils is licensed as GPLv3. Utilities it provides are provided by busybox
    in Yocto.

15. cross compilation and the triplets (host, target, build)
    -- different hardware architecture
       compiling a program destined for the MIPS arch on an x86 computer
    -- different operating system environments
       compiling a FreeBSD program under Linux
    -- different system library environments
       compiling programs for uClibc on a glibc host

16. make -C ld LIB_PATH=/usr/lib:/lib
    x86_64-lfs-linux-gnu-gcc: error trying to exec '/mnt/lfs/tools/bin/../lib/gc
    c/x86_64-lfs-linux-gnu/4.7.2/../../../../x86_64-lfs-linux-gnu/bin/as': execv
    : No such file or directory
    -- I'm actually using two machines to build this LFS. This might be the
       problem. Use one machine to build the whole LFS project. Record the files
       under /tools (-> /mnt/lfs/tools) in a record file each time a step is
       finished.
       [binutils pass 1]
       <output from command `ls -R /mnt/lfs/tools'>
       [gcc pass 1]
       <output from command `ls -R /mnt/lfs/tools'>
       ...

17. The whole steps of the LFS project all serve one purpose, that is,
    bootstrapping to a new platform. The basic steps of bootstrapping
    to a new platform are:
       *) build a cross compiler
       *) use the cross compiler to build necessary tools such as the
          operating system and a native compiler

18. Canadian Cross
    A technique for building cross compilers for other machines
    E.g.
    A: machineA, archA
    B: machineB, archB
    C: machineC, archC
    Use A to build a cross compiler that runs on B to create executables for C.
    step     compiler               output
    1         compiler on A        gcc(1), which runs on A and generates exes for A
    2         gcc(1)                gcc(2), which runs on A and generates exes for B
    3         gcc(2)            gcc(3), which runs on B and generates exes for C
    And gcc(3) is the final cross compiler we want.
    For example, we can use our x86 machine to build a cross compiler which runs
    on x86-64 machines and generates output for arm.

19. How does Yocto use the Canadian Cross tech to build its toolchain?

20. gcc and cross compilation
    build: the platform where gcc is built
    host: the platform where gcc is run
    target: the platform where gcc's output code is for

21. Compared with Yocot, LFS lacks the process of packaging as well as package
    splitting.
    Building LFS requires root priviledge while building Yocto doesn't. In fact,
    In Yocto, using the root account to build an image is forbidden.

22. Consider using fakeroot or pseudo in LFS

23. /dev directory population
    In LFS, the $LFS/dev is bind mount to the /dev directory on host.
    In Yocto, how is the /dev/ directory populated?

24. The package management scheme in Yocto is package archiving. That is, first
    install the files of a package into a seperate tree. After the installation,
    create a package archive using the installed files.
    Most package managers using this scheme will include dependency information
    into the package files. Well known examples are rpm, apt and opkg. But the
    inclusion of the dependency info is not mandatory for this scheme. Slackware,
    for example, uses a tar based system for package management. Its package
    manager does not handle dependencies.
    http://www.slackbook.org/html/package-management.html

25. LFS uses a unique scheme to manage packages, that is, the user based package
    management. The key problem of package management is to identify which files
    belong to which package. A general solution to this problem is to maintain a
    database which keeps this info. In a user based package management scheme,
    each package is installed as a seperate user into the standard locations.
    Thus, it's easy to identify by checking the user ID.

26. To deploy the LFS on mutiple machines, a few configuration files need to be
    changed. Here's a list.
    /etc/hosts
    /etc/fstab
    /etc/passwd
    /etc/group
    /etc/shadow
    /etc/ld.so.conf
    /etc/sysconfig/rc.site
    /etc/sysconfig/network
    /etc/sysconfig/ifconfig.eth0
    (mount point, network, hostname, user, group)
    A related bug in Yocto: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3252

27. The final LFS system is constructed in a chroot environment while in Yocto,     we do not chroot to create the final rootfs.