Writing your software to directly use the syscalls of a specific kernel does not make it "zero dependency", it makes it "one dependency" - and non-portable.
TBH I have mixed feelings about this approach. It's true that this is more or less what Go or (Cosmopolitan libc) do, but the motivation in their case is to maximize portability (by making cross-compilation trivial). However when you #include <linux/...>, you not only make your software non-portable, you also make it a PITA to cross-compile as you need the kernel headers on the host machine.
In contrast, with Go or cosmo, I can trivially build a tiny /sbin/init for amd64 Linux, pack it up with cpio, and run it with qemu-system-x86_64 -initrd - all from a Mac/arm64 host.
> However when you #include <linux/...>, you not only make your software non-portable, you also make it a PITA to cross-compile as you need the kernel headers on the host machine.
Yes, that is certainly a problem that I need to solve.
I added some support for cross compilation in the makefile. It currently requires clang for that.
ifdef TARGET
ifndef UAPI
$(error UAPI must be defined when cross compiling)
endif
TARGET.triple := $(TARGET)-unknown-linux-elf
override CC := clang -target $(TARGET.triple)
else
TARGET := $(shell uname -m)
endif
With this, I was able to cross compile lone for x86_64 from within the Termux environment of my aarch64 smartphone. All I had to do was obtain the Linux user space API headers for x86_64. Getting those headers was somewhat annoying but doable, there are packages for them in many Linux distributions.
I made a Termux package request for multiplatform Linux UAPI headers specifically so I could cross compile lone but unfortunately it was rejected.
Surely its more than one dependency. For example, you'll need a processor. Not just any processor, but a processor for which a C compiler has been written.
Like sibling comment points out, the CPU and the rest of the universe can be considered indirect dependencies. Once you have everything you need to boot the Linux kernel (e.g. laws of physics, paid the power bill...), you're good to go ;)
For that matter you’ll need a universe, the physics of which must allow both semiconductive metals and the eventual evolution of multicellular biochemistry.
At that point we really get into semantics... But now that you mention it, I would be interested to see if it could be built with APE to benefit from their bare metal support.
It does.
Writing your software to directly use the syscalls of a specific kernel does not make it "zero dependency", it makes it "one dependency" - and non-portable.
The author elaborates on their rationale and the technical details in a blog post: <https://www.matheusmoreira.com/articles/linux-system-calls>
TBH I have mixed feelings about this approach. It's true that this is more or less what Go or (Cosmopolitan libc) do, but the motivation in their case is to maximize portability (by making cross-compilation trivial). However when you #include <linux/...>, you not only make your software non-portable, you also make it a PITA to cross-compile as you need the kernel headers on the host machine.
In contrast, with Go or cosmo, I can trivially build a tiny /sbin/init for amd64 Linux, pack it up with cpio, and run it with qemu-system-x86_64 -initrd - all from a Mac/arm64 host.
> However when you #include <linux/...>, you not only make your software non-portable, you also make it a PITA to cross-compile as you need the kernel headers on the host machine.
Yes, that is certainly a problem that I need to solve.
I added some support for cross compilation in the makefile. It currently requires clang for that.
With this, I was able to cross compile lone for x86_64 from within the Termux environment of my aarch64 smartphone. All I had to do was obtain the Linux user space API headers for x86_64. Getting those headers was somewhat annoying but doable, there are packages for them in many Linux distributions.
I made a Termux package request for multiplatform Linux UAPI headers specifically so I could cross compile lone but unfortunately it was rejected.
https://github.com/termux/termux-packages/issues/16069
Surely its more than one dependency. For example, you'll need a processor. Not just any processor, but a processor for which a C compiler has been written.
Like sibling comment points out, the CPU and the rest of the universe can be considered indirect dependencies. Once you have everything you need to boot the Linux kernel (e.g. laws of physics, paid the power bill...), you're good to go ;)
For that matter you’ll need a universe, the physics of which must allow both semiconductive metals and the eventual evolution of multicellular biochemistry.
That's a great question... I wonder if Justine would be interested in that. She has her own sector lisp too.
At that point we really get into semantics... But now that you mention it, I would be interested to see if it could be built with APE to benefit from their bare metal support.