YouTube video by KoopertrooperGaming

The new Firebuild release contains plenty of small fixes and a few notable improvements. ## Experimental macOS support The most frequently asked question from people getting to know Firebuild was if it worked on their Mac and the answer sadly used to be that well, it did, but only in a Linux VM. This was far from what they were looking for. 🙁 Linux and macOS have common UNIX roots, but porting Firebuild to macOS included bigger challenges, like ensuring that `dyld(1)`, macOS’s dynamic loader initializes the preloaded interceptor library early enough to catch all interesting calls, and avoid using anything that uses `malloc()` or thread local variables which are not yet set up then. Preloading libraries on Linux is really easy, running `LD_PRELOAD=my_lib.so ls` just works if the library exports the symbols to be interposed, while macOS employs multiple lines of defense to prevent applications from using unknown libraries. Firebuild’s guide for making DYLD_INSERT_LIBRARIES honored on Macs can be helpful with other projects as well that rely on injecting libraries. Since GitHub’s Arm64 macOS runners don’t allow intercepting binaries with arm64e ABI yet, Firebuild’s Apple Silicon tests are run at Bitrise, who are proud to be first to provide the latest Xcode stacks and were also quick to make the needed changes to their infrastructure to support Firebuild (thanks! ). Firebuild on macOS can already accelerate simple projects and rebuild itself with Xcode. Since Xcode introduces a lot of nondeterminism to the build, Firebuild can’t shine in acceleration with Xcode yet, but can provide nice reports to show which part of the build is the most time consuming and how each sub-command is called. If you would like to try Firebuild on macOS please compile it from the GitHub repository for now. Precompiled binaries will be distributed on the Mac App Store and via CI providers. Contact us to get notified when those channels become available. ## Dealing with the ‘Epochalypse’ Glibc’s API provides many functions with time parameters and some of those functions are intercepted by Firebuild. Time parameters used to be passed as 32-bit values on 32-bit systems, preventing them to accurately represent timestamps after year 2038, which is known as the Y2038 problem or the Epochalypse. To deal with the problem glibc 2.34 started providing new function symbol variants with 64-bit time parameters, e.g `clock_gettime64()` in addition to `clock_gettime()`. The new 64-bit variants are used when compiling consumers of the API with `_TIME_BITS=64` defined. Processes intercepted by Firebuild may have been compiled with or without `_TIME_BITS=64`, thus `libfirebuild `now provides both variants on affected systems running glibc >= 34 to work safely with binaries using 64-bit and 32-bit time representation. Many Linux distributions already stopped supporting 32-bit architectures, but Debian and Ubuntu still supports armhf, for example, where the Y2038 problem still applies. Both Debian and Ubuntu performed a transition rebuilding every library (and their reverse dependencies) with `-D_FILE_OFFSET_BITS=64` set where the libraries exported symbols that changed when switching to 64-bit time representation (thanks to Steve Langasek for driving this!) . Thanks to the transition most programs are ready for 2038, but interposer libraries are trickier to fix and if you maintain one it might be a good idea to check if it works well both 32-bit and 64-bit libraries. Faketime, for example is not fixed yet, see #1064555. ## Select passed through environment variables with regular expressions Firebuild filters out most of the environment variables set when starting a build to make the build more reproducible and achieve higher cache hit rate. Extra environment variables to pass through can be specified on the command line one by one, but with many similarly named variables this may become hard to maintain. With regular expressions this just became easier: firebuild -o 'env_vars.pass_through += "MY_VARS_.*"' my_build_command If you are not interested in acceleration just would like to explore what the build does by generating a report you can simply pass all variables: firebuild -r -o 'env_vars.pass_through += ".*"' my_build_command ## Other highlights from the 0.8.3 release * Fixed and nicer report in Chrome and other WebKit based browsers * Support GLibc 2.39 by intercepting pidfd_spawn() and pidfd_spawnp() * Even faster Rust build acceleration For all the changes please check out the release page on GitHub! (This post is also published on The Firebuild blog.)