Hacker News Reader

Comment by kentonv | Hacker News Reader

I like this a lot more than I should. :)

Somehow I've always found system calls far more pleasant to use than "section 3" C library interfaces, and it makes me sad that I'm pulling in some 3MB of library code (libc + libm + pthread; not even counting the dynamically-loaded stuff like nsswitch) that I mostly don't want.

Sadly as a C++ programmer I do at least need libgcc to implement exceptions, which in turn likely pulls in glibc anyway. Sigh. (And I haven't completely cut ties with libstdc++ yet, though I'm close...)

(And yeah, on typical system these libraries are already resident anyway since other apps are using them, so wanting to avoid them is mostly silly, but it feels nice!)

View on HN

> And yeah, on typical system these libraries are already resident anyway since other apps are using them, so wanting to avoid them is mostly silly, but it feels nice!

In principle, shouldn't avoiding those libraries make code friendlier to the instruction cache, even if the libraries are already in memory? (yes, I'm also trying to justify the inherent niftyness of this...)

The major niftyness of the static linking (it doesn't have to be minimally minimal) on Linux is that it's the only way I know of (1) to have a nice portable executable for every x32 Linux or for every x64 Linux, no matter who made the distro and what he put inside of it.

At the moment, Windows has an advantage: even if some fractions in Microsoft don't like to support that (2), Windows has a single C crt dynamic library which is compatible through the different versions of Windows, which can give you an extremely small portable binary which also links the C crt library (the starting size of your such binary is typically around 3 KB on the Win64, if I remember).

----

(1) If somebody knows anything else please say!

(2) Modern versions of Visual Studio are intentionally made to not link to that C crt lib. You have to jump through the hoops.

I've crashed into an issue where "crtdll.dll" did not manage to get installed on a fresh XP, so software relying on its presence died mysteriously.

First level support for that software didn't understand what I was going on about.

> Somehow I've always found system calls far more pleasant to use than "section 3" C library interfaces

I'd rather not re-write fprintf, myself, but I suppose that's up to you. ;)

There are some good functions implemented in the kernel instead of libc, but I personally think fork() and pthread_create() are more intuitive than learning what exactly Linux expects from a clone() system call, even assuming it's fully-documented. (Which, to be fair, it likely is. This isn't Windows; the Linux kernel API is stable and meant for public consumption.)

My main point is that a kernel (as opposed to a VM) is an abstraction anyway, so I might as well pick a convenient abstraction, regardless of where the code to implement that abstraction happens to live.

If you use -ffreestanding -nostdlib, libgcc doesn't pull in libc. You'll need to write the syscall(2) function yourself.

Somehow I've always found system calls far more pleasant to use than "section 3" C library interfaces

I agree, and I think it has to do with the fact that parameters are always passed in registers, and error returns are quite straightforward (negative of the error number) as opposed to the C interface convention of returning only -1 and putting the error number in errno.

>>I'm pulling in some 3MB of library code that I mostly don't want.

Doesn't LTO fix that?

If you can get it to work... We've had lots of problems with LTO and arm-none-eabi-gcc.

Reply on news.ycombinator.com