one package down. many more to go. i copied the dependencies list for debian apt-get, to a file for openbsd. now i'm adapting it. i just installed "acpica" openbsd package, equivalent to debian acpica-tools.

i may have to port some dependencies.

beyond that, adapt lbmk e.g. make it automatically use gmake and gcc, not bsd-made and clang, on various upstreams. may have to patch a few upstreams.

coreboot and grub already somewhat accomodate bsd.

i'm porting libreboot's build system to openbsd

today's mood

shitbox$ doas ./mk dependencies openbsd
./mk: include/init.sh[482]: no closing quote

this is *not* a trivial project. i've already found many linuxisms in the libreboot build system.

but more than that: libreboot heavily relies on GNU tooling in its build process. think gcc, binutils, autoconf and so on.

openbsd has GNU tooling in base, but much older tooling for certain parts of base. these are not to be used. when you install e.g. gcc from ports, you get e.g. /usr/local/bin/gcc-VERSION. i will have to handle this in lbmk. doing so reliably, and automatically, is non-trivial.

@libreleah building it with musl instead *think*

@april libreboot already builds just fine on musl, in linux distros that use it, e.g. alpine linux

@libreleah i meant using musl on BSD to build libreboot instead of gcc

@april why would i do that?

@april and isn't musl just a libc?

@april i mean, i could bootstrap everything from source. some parts still need a package, e.g. gnat needs gnat to compile.

openbsd pretty much freezes packages in each release, so tailoring per-release is feasible. then just continually update for current too (for dependencies and such).

detect openbsd version in lbmk and adapt accordingly, use specific versions of things. e.g. /usr/local/bin/autoconf-2.72 currently, on obsd -current.

just populate a fake PATH with symlinks e.g. gcc->gcc-15.x

@libreleah yea, i did not have a coffee this morning, i was more thinking ig musl + clang or smth if gcc is too much of a pita (and ig them computing nerds in my bubble prefer musl over glibc)

@april but why use musl? i'm unsure if musl would even work on bsd to begin with, since large parts of it are using linux syscalls for things. openbsd already has a competent libc in it that i can just use.

@libreleah oh i did not know that. The nudl part really is just people fangirling over it, excuse my lack of knowledge

@april have you used a bsd system before? just to be clear, i'm not porting libreboot to a linux system :)

i like musl. i like rich felker. both are awesome, but these have nothing to do with openbsd.

@april musl and openbsd libc are already pretty similar anyway. felker is really conservative about features in musl and models the design of musl directly on inspiration by bsd projects. but musl is written for linux systems.

@libreleah ive used OpenBSD before but probably less than you haha

@april i mean it's basically linux, from a universe where good software design is the norm. that's all i have to say.

@libreleah also i only used it for routers or @ work (dns) before

@april but yeah so like, in linux, you just... install gcc right? and run gcc. it is not like that on bsd systems. there are like 20 different versions and you pick one. "gcc" in PATH, in openbsd, is a really really old one in the base system.

if you're using stuff like gnu toolchains in ports, you run e.g. gcc-15, gcc-14, and so on.

so you h ave to adjust PATH and/or adjust e.g. CC, and so on, in the environment. often you have to patch upstream projects if they assume e.g. gcc in PATH.

@libreleah i mean yes that far i know ^^

i never had to deal with plain kernel syscalls myself (i should probably do that at some point) so thats the part where i had the lack of knowledge

@april

well on any linux system that has headers and stuff installed, just do

man syscall
man syscalls

and it has information

@april btw don't worry, it's cool. lots of people assume that the way linux, and linux distros, do things, is the norm/normal. as soon as you use not-linux, things get a bit hairy. but i think the bsd way is better, in this regard. i can use a specific version of bsd and i always know what's what. if my program is using a specific version of gcc, i'm not suddenly caught out later when the version charges. just directly calling cc unversioned seems silly once you look at bsd.

@libreleah
✔ code stuff for coreboot
✔ code stuff for userspace
⚔️ code stuff with syscalls

@april i already have partial handling of this in libreboot, because at one point i was build-testing libreboot on debian sid and the proper gcc version wasn't available at gcc in PATH. but i had e.g. gcc-15, and then gnat-13 and gnat-14. and gcc-13. and i had to make lbmk match them up in terms of version.

i can just extend that logic to the entire system toolchain, for each component e.g. autoconf, autogen, and other tools.

some tools are unversioned. e.g. iasl is just iasl, in openbsd.

@libreleah thats not new to me in the regard that its the same in linux if u install multiple gcc / clang versions, at least in some distros! so this should be the default imo

@april yeah well on linux, i expect (and demand) that users build it in debian and arch linux. if it works in other distros though, that's cool too. but yeah. toolchains get messy.

i'd just bootstrap everything from source, but that's its own nightmare. i could do that. openbsd comes with modern llvm tooling in base, that can bootstrap nearly everything.

gnat (gnu ada compiler) needs to be built with ada (binary bootstrap), so i'd at least have to handle that from the ports system in openbsd.

@april thing is, openbsd already has a ports system, which already handles building a bunch of things from source. i can just integrate use of that in lbmk probably. it's possible to run the ports system as a normal user too.

openbsd isn't designed for what i want to do. but i'm used to things not being designed for what libreboot wants to do. i just add a million hacks until it works :S

@libreleah for nix i could build / upstream a build script at some point, thats the cool part on nix that everything is versioned

@april i'm against use of nix in lbmk. because it's a very large dependency. it's only simpler from the user's perspective. the actual amount of code you end up running on your system is extreme. i prefer to eliminate such abstractions, in my designs.

@libreleah not inside of it but as a alternative way to build it, but fair point! it only makes sense for people already deep in the ecosystem like me who have a huge array of build servers

@april it's just like when people tell me i should rewrite libreboot's build system in python or something. python's infrastructure is millions of lines of code. your shell is like 15,000 lines of code. i choose to write everything as shell scripts. shell scripts don't break.

unless you use nested quotes inside of backticks, and then one day decide to use your build system in openbsd. but i'm working on that!

@libreleah i mean that works ye!

@libreleah to be fair i can also do that as a seperate repo. my idea would more be to use nix to setup a enviroment for lbmk that has all the needed libraries required by it

@april git clone https://codeberg.org/libreboot/lbmk

then read the main "mk" script, and everything under include/, in that repo.

you will see my madness, and my passion, in those scripts.

@libreleah nah nah its not even that ^^ i think if a build system works it shouldnt be changed, your 15k lines of code will still run better than the current state of C build systems for many targets haha

@april usually when lbmk breaks, it's not lbmk. it's gcc changing something, and i make a small patch to an upstream project or something. lbmk is 2800 lines of shell script, and i can reliably build libreboot on all of the major distros, on multiple versions of them. i cannot say the same for many other build systems.

nix-based projects end up having a higher maintenance burden, because now you are dealing with a lot more moving parts and its design is biased to upstreams (you're not upstream)

@april if you look at the design of lbmk, everything is completely generalised. you will find very little project-specific logic in the libreboot build system whatsoever. e.g. look at include/tree.sh - this builds grub, seabios, coreboot, grub, various utils, and even u-boot. it could even build a linux kernel, with zero code changes, you just need to add a config - it natively supports scons as a build system, and knows how to operate it fluently.

@libreleah yea nix packaging is always trying to emulate the expactations of what upstream thinks their build environent shouöd be

@april when i add new codebases to lbmk, i very often do not need to modify lbmk at all. often all i need to do is specify an upstream, a revision, and maybe add some patches.

now grep for "mkhelper", "premake" and "postmake" in those files. project-specific logic can use these, when a given project needs custom logic, alongside the generic build logic.

lbmk can build anything. i could probably bootstrap a full linux distro with it, if i were insane enough.

@april the reason people use stuff like nix is the same as e.g. containers. they want to ensure a specific environment, with sane versioning and so on. this mitigates breakages too, like if you have a legacy codebase that needs to compile on old gcc or something. but you're just delaying the pain. and you end up adding technical debt, and suddenly you're running millions of lines of code.

@april me?

i maintain kgpe-d16 support in libreboot for example. no container, no nothing. i patch it to build on modern distros without containment. who needs that bloat?

and i'm not scared to modify a decade-old version of gcc e.g. gcc 8.3 as used in coreboot 4.11 (which kgpe-d16 currently uses, in libreboot)

that's coreboot from 2019 btw. you have no idea the lengths i go to make that build. i could have used docker. lots of other coreboot distros use docker and nix.

libreboot stays pure.

@april when you use something like docker/nix, docker/nix itself becomes a liability, and now you're maintaining *that*. i see projects using it always patching themselves for changes make upstream to those systems. and they don't fix anything. all you're doing is emulating a bitrotting version of $whatever, forever.

@april and docker/nix are very much linux-centric. i want my shit to run on bsd.

@libreleah @april nix isn't linux specific. officially it also supports macos (ew) and there seems to be a FreeBSD port too

@noisytoot @april the rest of my arguments against its existence and efficacy shall remain.