But also hilariously still paying the runtime cost of ELF dynamic linking instead of just static linking so at least you avoid, e.g. GOT indirection overhead.

▲

Joel_Mckay 3 days ago | parent [-]

Again, static linking would only be useful in a single unique App run and dump scenario. People do link and strip .a sometimes when porting to Windows and MacOS.

Some programs take a huge memory and performance hit on non-Linux machines. =3

▲

quotemstr 3 days ago | parent [-]

> Some programs take a huge memory and performance hit on non-Linux machines

You're implying without stating it (or providing any evidence) that programs perform worse when statically linked than when assembled out of ELF DSOs, even when each of those DSOs has a single user.

That makes no technical sense. Perhaps you meant to make a different point?

▲

Joel_Mckay 3 days ago | parent [-]

An 8kB program loads and runs much faster if the .so it uses is already cached due to prior use.

A 34MB static built version will cost that amount of i/o every single instance on a system that did not cache that specific program previously. Also it will take up that full amount of ram while loaded every single time it runs.

Inefficient design, but works fine for other less performant OS =3

▲

quotemstr 3 days ago | parent [-]

> 34MB static built version

I've forgotten how to count that low.

Also, static programs are demand paged like anything else. Files aren't loaded as monoliths in either case. Plus, static linking enables better dead code elimination and devirtualization than is possible with an AOT-compiled and dynamically linked setup, which usually more than makes up for the text segments of shared dependencies having been pre-loaded.

I'm not sure you have enough technical depth to make confident assertions about linking and loading performance.

> =3

The "blowing smoke" emoticon isn't helping your argument.

	▲	Joel_Mckay 3 days ago \| parent [-]
		If a stripped static linked library saved that much space, than people probably chose the wrong library resources. Sometimes ripping off unreachable areas also has unintended consequences, but stripping debugging resources is usually safe. If .so reuse is low, or the code is terrible... it won't matter much. Best of luck =3