4 ms·
That post keeps being linked in these discussions but it's highly misleading. > Do your installed programs share dynamic libraries? > Findings: not really Th
by comex 4y ago
That post keeps being linked in these discussions but it's highly misleading.
> Do your installed programs share dynamic libraries?
> Findings: not really
The posted findings actually show that common libraries ranging from libc to libX11 are used by high-hundreds to thousands of binaries. The fact that there are also a lot of not-widely-shared dynamic libraries doesn't seem particularly significant.
> Wouldn't statically linked executables be huge?
> Findings: not really
> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies. A good linker will remove unused symbols.
This analysis is completely wrong because it ignores the effect of transitive dependencies. If all exported symbols are independent and don't depend on anything else, then using 4.6% of the symbols means the linker can strip the library down to 4.6% of the size. Simple libraries like libc or libm are pretty close to that ideal. But for more complex libraries, the exported symbols are just the entry points for a deep nest of interlinked functions, and often a single symbol will transitively depend on a large fraction of the library.
- josephg 4y ago> This analysis is completely wrong because it ignores the effect of transitive dependencies. I hear your criticism, and I'd love to see the corrected results for this. My instinct is that most fully statically linked binaries wouldn't be that much bigger than their dynamically linked counterparts even with transitive inclusion. But I don't know for sure. Honestly I'm surprised its not easier to run these experiments. If dyld can traverse the call graph through dynamic libraries, why can't it just output the result as a single statically linked binary? I don't know how useful this would be - and it would miss out on inlining & optimization opportunities. But it'd be great for these sort of questions.
- atq2119 4y agoAt least with ELF, shared libraries are organized into segments and you really only have a handful of them. The information about where individual function boundaries are has been thrown away and in principle this can matter, e.g. if cold code was moved away from hot code. Therefore, the linker can't just split the segments apart. As for your instinct, it'd be wildly wrong depending on the use case. Maybe if you only link with libc, sure. But now consider linking against something like a GUI framework...
- gpderetta 4y agoA better test would check at any point in time how many running programs are sharing object files and how much memory is saved.