Beigesoft™ Linux From Source Code (LFSC).

Why build Linux from source code?

The most Linux distributions are provided as binary packages. Many Linux vendors stop provide 32bit versions. Sometime they provide non-well updates, and it's take a time to resolve problems (issues). So, at first, it's about achieving independence and reliability.

Building/compiling methods.

The first method is the native compiling method into the current root "/". You can compile by this method any high-level application, e.g. a music player. It's needed a building environment to do this. This is a minimum set of program and libraries, such as glibc, gcc, binutils, bash... To make a building environment from source code you should use the cross compiling method.

The second method is cross-compiling. This is building a binary into a different root, even for different architecture, e.g. building for an ARM (tablet OS) on a x86 PC. This is only method for tablet's/mobile's OS. There are the four main standard variables to do this:

  • --sysroot - tells compiler where search the headers, and to linker where search the libs (where is the new sysroot)

  • DESTDIR - tells "make" where is the new root directory to install this software

  • --host - tells "configure" what is target (built/compiled) architecture

  • --build - tells "configure" what is building(compiling) architecture, without it "configure" will think that it's a native compiling, and "host" just point to proper sub-architecture, e.g. i786-pc-linux-gnu

There is also "--target" for building compiler tools for cross-compiling (gcc, binutils).

There is also compiling with CHROOT method, it is native-like method, LFS uses it. This method can't be used for different architecture or for too different versions of compiling and compiled (target) systems, e.g. compiling Linux has kernel4 and glibc2.24, but compiled Linux has kernel5 and glibc2.31(with minimum kernel 5).

Autotools's --host, --build and --target vars are also used for compiling for current computer multi-arch tools and libs.

The main problem is that even low level software doesn't respect cross compiling with "--sysroot" method. Only compilers properly treat "--sysroot", i.e. they search the headers in the "target root". Native LD treats "--sysroot" as "additional root", so you must pass "-L[DIR]" to change priority of target libs. Autotools also mix native and target roots. Built(compiled) software may run just compiled libraries for building itself, so it will fail for different architecture target. Even though CHROOT method often faces such problems, e.g. coreutils's error help2man: can't get `--help' info from man/dir.td/dir. It seems that the cause is confusing about native and target libraries/settings files. Testing is also the problem (in case of cross-compiling for a regular computer). Of course, special building systems for tablet's OS handle those problems.

Classic building (native compiling on a regular computer) deals with already installed libraries. It's often deal with cross (mutual) dependencies, e.g. compiling SYSTEMD depends on DBUS and vice versa. Even though the main library GLIBC requires SELINUX for supporting it (of course, it's never be linked to libselinux), so repeated compiling is needed for software with cross(mutual)-dependencies. You can check it by configuring GLIBC with "--with-selinux", it will blame if SELinux library not found. Facing two facts - "repeated compiling because of cross(mutual) dependencies" and "cross-testing problem" leads to proper way of building LFSC:

  1. pure cross-compiling (without chroot) including building software (gcc, binutils, make, etc.), i.e. making raw LFSC

  2. pure native-compiling (including tests and cross(mutual) dependences) all software again on newly born raw LFSC

It's used truly "cross-compiling" (without chroot) then "native-compiling" methods for making Beigesoft™ Linux From Source Code multi-arch (64/32bit) since version 1.5. 32bit libs (i386) are needed for Android developing. x32 seems to be useless.

Because of cross-compiling is difficult in many cases, since version 1.6 LFSC is built in this way:

  1. cross-compiling minimal self-build-able Linux with building software (gcc, binutils, make, etc.) without many ones like systemd. It will be kernel, bash (as init program), nano, m4...

  2. native-compiling stage 1 without testing up to systemd and dbus on init-bash booted LFSC.

  3. native-compiling/recompiling stage 2 (including tests and cross(mutual) dependencies) all other software on init-systemd booted LFSC

Since version 1.6 it's used the newest software source code to build LFSC, e.g. Kernel-5.5.2, GLIBC-2.31, SystemD-244, Gcc-9.3.0... Building system is still the same - Debian 9.

Screenshot LFSC 1.8: