4.6 KiB
+++ title = "Testing, some reversions, build enhancements, and the kernel" date = 2020-07-03 [taxonomies] tags = ["Libraries"] +++ A lot has happened behind the scenes here. Not surprisingly, much of it has involved bug squashing and testing.
First, the wild libc tangent. I spent around a week taking a much closer look at musl libc than I ever have previously and through much trial and error managed to compile the complete HitchHiker base system. I'll devote a full post to this at a later date, but to briefly sum up where things stand, there is enough still standing in the way to give me pause about moving to musl at the present time. HitchHiker has a number of goals in mind, and one of the main goals is the ability to relatively easily bootstrap the system from source while running a different Linux distribution. The build process currently involves three passes each of building gcc and binutils and two passes at Glibc. Going with musl would introduce quite a bit of additional complexity, as the only way I got it to fully work, coming from a Glibc based distro, was to build the full temporary toolchain, build the cross compiler and linker using the temporary toolchain (and linking to the temporary glibc in /toolchain), and then bootstrapping a native musl compiler from within a chroot.
Additionally, during testing I uncovered some unexpected behavior in the compiled system. I hesitate to blame musl, as it is entirely likely that the offending packages are expecting Glibc and thus perpetuating some "gnuism's" that break compatibility with other libc implementations. As an example, the passwd utility from the shadow package does not wait for the user to input the new password, but skips right past and spits out a "password unchanged" message. Changing password worked using usermod and passing the password as an argument on the command line. Most likely this could be relatively quickly fixed, but it gives me pause to think that there could be any number of other future issues of this sort when replacing our libc.
So long story short, we're forging ahead with Glibc for the present. I did some work to implement some configurability in the build system and created a mechanism whereby the installed locales can be chosen at the time the system is built. The default still compiles and installs all locales supported by Glibc. If one copies the file locales.mk.all to locales.mk and uncomments the lines for the desired locales, then only those locales will be compiled and installed. This saves some space and some fairly significant compile time. There is about a 9 minute difference between installing only en_US.UTF-8 and en_US.ISO-8859 and installing all supported locales on my laptop.
Another bug became apparent only after rebuilding world with a fresh rebuild of the temporary toolchain. Originally we had replaced the full gettext suite with gettext-tiny, courtesy of Sabotage Linux. Apparently, vim had been using msgfmt from the temporary toolchain, which was an older build and the full binary from gettext. When the only binary available was the gettext-tiny version, it segfaulted during the vim build and compilation stopped. The only options were to hack the vim build system, disable nls in vim, or reinstate GNU gettext. At this juncture we're using gettext-tiny in the temporary toolchain and GNU gettext in the completed system, as I feel native language support should not be sacrificed in favor of a smaller system. HitchHiker should be fully functional whether one is based in an English speaking country or Cambodia.
The next bug which was uncovered only reared it's head when trying to compile the kernel. We were using libelf-compat, again from Sabotage, which is a cutdown older version of elfutils with a cleaned up build system. During the kernel build there were cryptic errors about the size of symbold being larger than the size of the files with certain modules. Replacing libelf from libelf-compat with that from the current version negates the issue.
On to the still incomplete kernel build system. Some work has been done here, but it's not yet fully functional. Complicating matters, we're going to be using the most current mainline kernel on x86_64 and the RPI foundation's kernel on RPI. Default configurations have been generated, and the plan is to use those if the user does not intervene but allow for customization in two places. The first place will be an ability to pass the build system a path to a different configuration that can be maintained by the user. The second will be a variable that can be passed that will drop the user into the Kbuild menuconfig target before building the kernel, in order to make any necessary tweaks.