Neon, but edgy

What's the point of statically linking libc? I've gotten the picture that there really aren't systems that don't have libc. Or is it just that dynamic linking is bad overall in some sense?

Pardon my possibly inaccurate wording, I'm still pretty new to low level stuff like this.

@neon my understanding is that you might want to have greater control hence you staticaly link over optimising for (the lack of) space.

I undsrstand nothing about the subject tho

@neon Don't BSD and Linux treat strings differently in their versions of libc?

@Canageek Quick googling revealed that apparently glibc has some functions that BSD libc doesn't. I'd definitely see this as a reason to statically link libc, just to avoid that mess.

@neon many who push static linking propose that the latter is true, and that dynamic linking is harmful and should not be used in the majority of situations

on systems with a sanely designed libc (ie, not glibc) you often end up with better performance and lower memory usage than if you dynamically link (despite dynamic linking supposedly being better for those things)

@neon it also entirely removes the issue of dependency hell in a distro

you only need to deal with dependencies while compiling, not to install the application

@ky0ko Fair points. Is glibc bad because of the extensions it makes to standard or something deeper? I noticed while googling that it seems to have some functionality other libc implementations don't have, which seems weird for an implementation of a standard.

@neon it has a number of nonstandard extensions, and also behavior that is incompatible with a standard libc

it is, by many accounts, badly written, bloated, and does things that make you have to target its behavior explicitly

@neon an alternative to it is musl, which is designed to be 100% standards compliant, and correct

@neon (this is what i'm using in the distro i'm building)

@ky0ko @neon doesn't musl keep around a lot of the gnu and linux extensions to ensure that software designed with only linux in mind actually still works

@scarlett @neon the fact that i've had to patch a bunch of stuff that expects glibc says no

@scarlett but it doesn't replicate the internal glibc headers that a lot of applications use even though they're not supposed to, it doesn't replicate a lot of gnu extensions

it does expect a compiler with __asm__

it does maintain a minor level of abi compatibility with glibc but all except the simplest applications will probably break if you try to drop it in place

@ky0ko Oh, that's good! When I first read about statically linking with Rust* I saw that you could statically link with musl, and wondered why that, not just your system libc. I guess that explains it!

* Well, it links rust dependencies statically by default, but like properly statically linking everything.

@neon glibc is so bad that even if you *do* statically link it, it's not portable, because it uses dlopen to open nsswitch plugins which may well have different symbol versions. Openssl has something similar.

In that light - the light of how non-portable dynamic linking is and how much people *do* want to distribute binaries instead of source and a compiler - static linking makes so much sense.
@neon sure, theoretically dynamic linking is better, but the way it's implemented and used in practice is fucking horrific
@neon and in these days of ample storage and memory, static linking the the easiest, simplest, and most currently available solution to how fucked up shit is.

@kurisu @kurisu So it seems. I dig the idea of not requiring the user to install prerequisites, so I've kinda liked the idea anyways, but it definitely seems like static linking is the way to go anyway, if it's in any way practical.

@neon unfortunately it's still pretty impractical unless you distribute a alpine chroot with your compiler, or do what go did and just rewrite everything in go so that they don't have to deal with C at all.
@neon not really, it just shows you how much work and how long you'll spend compiling if you want a working musl libc

and after you have the musl libc you still need to recompile all the other C libraries you depend on. And crystal depends on many more than rust, because it's a less mature language with a larger stdlib (particularly regex and evented IO)
Sign in to participate in the conversation

@neon's personal instance.