Build with `gcc -std=c99 -ffreestanding -nostdlib`. After -Os and strip, a.out is 1232 bytes on my system. I got it to 640 bytes with `strip -R .eh_frame -R .eh_frame_hdr -R .comment a.out`.
Starting at ~640 bytes, maybe you could come close to asmutils' httpd in binary size. Failing that, take a look at [1]
You can get pretty far without a real libc, keeping in mind:
- You probably want fprintf, and things can be slower without buffered IO (due to syscall overhead)
- `mmap/munmap` is okay as a stand-in allocator, though it has more overhead for many small allocations.
- You don't get libm for math helper functions.
Of course, you can cherry-pick from diet or musl libc if you need individual functions.
Thanks for this Ryan. I'll reference this gist too. I remember starting with something like this early on (w/o your sysdef) but wanted argc, argv, envp and to separate syscall* from the startup code.
Part of the reason I've started this is that libc suffers from bad design (in von Leitner's definition [0]). I find c0's & djb's APIs better designed [1][2]. *printf is a prime example of bad design. Heck, pretty much everything in stdio.h & string.h has a design flaw)
And the good thing for the statically linked executables is that the binary can work on every Linux as the syscall interfaces remain the same. The critical point is not depending on something else platform specific other than the syscalls, but for some kind of utilities its doable.
- Portable (as long as you don't need dlopen/dlsym). If you do need to dlopen other libraries, you can run into issues on ARM mobile with mixed soft/hardfp calling conventions. Otherwise you're fine if the ABI is solid.
- No need to atomically update your system, as applications stand alone.
- Slightly faster program startup time.
Cons:
- Slightly larger file size (assuming you linked glibc... doesn't apply so much to things like musl or lib43).
- You can't link in OpenGL client libraries, so games will probably still need the dynamic linker.
Build with `gcc -std=c99 -ffreestanding -nostdlib`. After -Os and strip, a.out is 1232 bytes on my system. I got it to 640 bytes with `strip -R .eh_frame -R .eh_frame_hdr -R .comment a.out`.
Starting at ~640 bytes, maybe you could come close to asmutils' httpd in binary size. Failing that, take a look at [1]
You can get pretty far without a real libc, keeping in mind:
- You probably want fprintf, and things can be slower without buffered IO (due to syscall overhead)
- `mmap/munmap` is okay as a stand-in allocator, though it has more overhead for many small allocations.
- You don't get libm for math helper functions.
Of course, you can cherry-pick from diet or musl libc if you need individual functions.
[1] "A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux" http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...