The original words of Phanes, tirelessly carved into a slab of "No'".

Dissecting SYSROOT Cross-Compilation

I finally had a little time, so I thought I’d cycle through some projects, and today I’m looking at SURRO Linux’s FOSTER build effort.

Building a Linux system from source is kind of an old world mystery to me for some reason. I spent years learning package management, system administration, software development, systems design, and a few other areas only to find this raging gap in skills when it came time to roll my own.

Most of those gaps are around unusual uses of those lower level tools and processes that you just don’t get alot of exposure to in large scale enterprise systems and software. Those jobs that demand “senior linux systems engineering” experience that claim to be linux heavy are actually ridiculously light in terms of how much knowledge of Linux operating systems is actually required. You could easily float through an entire career in the Linux space with little to no training these days. Not because of advancements, but because of decay. I’ve all but given up trying to keep my Linux chops sharp through my contracts alone, because it just isn’t possible.

I am just pulled too many directions to read the years worth of books I’ve acquired on the topic of cross-compilation, compilers in general, open source systems, and the linux kernel, so, I think today I’ll do some condensation of various different methods publicly available, see where the common steps are, and try to synthesize a good high level method that will fit into what I’ve been building so far.

Besides the obvious Linux From Scratch project, there’s the Build Your Own Linux project which is also getting popular:

http://www.buildyourownlinux.com/

I want to understand the bare minimum requirements to do this, so I’m taking a kind of backwards approach.

Minimal System Build

Set up your environment: Set some environment variables, create some directories with some permissions. Skipping all pieces of that until I have to do something to move forward.

Download your sources. Skipping all pieces of that until I have to do something to move forward.

Replace some packages with their gnu coutnerparts. Skipping all pieces of that until I have to do something to move forward.

The Build System: Why Not Fedora?

Set up your build system. Now this is one I kind of have to do to move forward, and it’s unfortunately a little political.

I love Fedora.

So in my case, for Foster I’ve been planning on using Fedora 32 as my base system since I can install dependencies on my build host with dnf/yum, which is super convenient, but, Fedora has become politically unstable, so, any project using it this way is threatened existentially by the reliance on it:

https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedoraproject.org/thread/M3W2Q6P6NSZJ2WQD4BJOTBBMUMOJ5K62/

I’m sure you can see what I mean. RedHat owns the Fedora Project, and RedHat is owned by IBM. For some strange reason, IBM, who bought RedHat to save itself from extinction over its own bad and innovation-resistant culture, believes that either RedHat or Fedora will be improved by inserting its generally anti-open-source and politically repressive cultural and contractual restrictions on those communities through designated culture shapers. This is an extension of a loosely collaborated effort a few years ago where several corporations started paying activist groups with specific agendas to inject themselves in open source communities and establish strangleholds on the culture under the thinly veiled guise of cancel culture rhetoric spawned by organizations like the Ada Initiative, which was really just culture shaping to prepare these communities for corporate takeovers. Much like its sister projects under RedHat, like the Python Software Foundation, Fedora is compromised by the IBM takeover, so, it’s not safe to rely on it and I don’t want to lose a release of my own thing because I built it on top of Fedora and then got disassociated because I didn’t kiss the right asses during the peak of the cancel culture era. Ridiculous that this even has to be a consideration.

In fact, most major stable distributions now are corporate owned and are in that category, so, I am almost wondering if using a FreeBSD system for the build system would be ideal. Since I want to target multiple architectures, it really would seem to make more sense. The only trouble I can think of is that one of the functional requirements is to use docker for environment segregation between the host system and the build system, which, if I understand correctly, won’t do FreeBSD containers on a Linux Host, and, docker is problematic on BSD systems. I also don’t want to introduce the requirement that the host system be a BSD system either.

In all reality, I think Debian is a better choice for this kind of thing. It’s package sets are a little more stable than most distros, and it’s way more burned in. I say Debian over Ubuntu as when I did an LFS build on an Ubuntu host I ran into all kinds of workarounds needed to get around the toolchain patches Ubuntu used that seemed to specifically target breaking these types of operations.

Just because these companies virtue signal about how opensource friendly they are because they included some bastardized version of an open source component in their service offerings doesn’t mean they’re playing nice with the open source community — and most people enabling them in the open source community aren’t realizing that while they make it worse. It’s kind of hard not to see if you look at it a little closer.

Debian also has these forces at work but I haven’t heard as much of the tectonic shifting from their end of the Linux multiverse. The sure giveaway is the Code of Conduct ratified in 2014. The 2014-2015 timerange was when these groups were dispatched and you’ll see a Code of Conduct pop up in most corporate backed opensource projects around that time. It’s a matter of time.

So, in my current thinking, Debian is a great bootstrap distro to use as a build system while they are playing out their lifespan, and then I can shift to the next version of SURRO to use SURRO as the build system and free myself from the whole madness altogether. From there, besides the obvious concern of ecosystem maintenance and its overhead, is idiots making the false assumption that SURRO would be based on Debian somehow after reading this because of the inclusion as a build platform in the first iteration, which is stupid, but I’ve already heard things like that about Fedora for the same reason on IRC; ironically Linux used to be where the smart people were.

The Build System: Debian

Moving on from the sheer madness that is Linux politics, in Foster, I’ve removed all the components and cleared out the plan file and unit definitions to start a little fresh and declutter.

To move from Fedora to Debian, I just update the dockerfile to say “FROM debian:stable” instead of “FROM fedora:latest”.

Now this part should be fun since I’m generally unfamiliar with debian package management.

At this point I realized Examplar needs some rework, so, I will revise this post once I’ve done that.

Next Post

Previous Post

Leave a Reply

© 2020 Phanes' Canon

Theme by Anders Norén