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.
install rpm packages into the rootfs
-> image cmd (genext2fs)
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
useradd -s /bin/bash -g lfs -m -k /dev/null 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)
*) interactive login shell
*) non-interactive shell with --login option
*) 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
*) 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
11. setting up a clean environment
cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
This ensures a clean working environment.
cat > ~/.bashrc << "EOF"
export LFS LC_ALL LFS_TGT PATH
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.
the final system
the temporary minimal system
binutils is licensed as GPLv3. Utilities it provides are provided by busybox
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
: 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
[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
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
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.
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.
(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.