Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic linking

drewdevault.com

Post reply on HN
Print view View original

171–180 of 249 posts

Re: Dynamic linking

#171

Post by cryptonector »

saurik wrote: post #168
cryptonector wrote: post #23

By far the most important reason for dynamic linking for C is semantics: static linking semantics are stuck in 1978 and suck (more on that below), while dynamic linking semantics make C a much better language. In particular, static linking for C has two serious problems: 1. symbol collisions -> accidental interposition (and crashes); 2. you have to flatten the dependency tree into a topological sort at the final link…

Most linkers support archive "groups" at the command line, so you don't need to do the topological sort. Most linkers also support relocatable objects, so you can trivially solve the symbol collision problem by just linking together a subset of your app and then stripping that symbol before linking the conflict. And like, it frankly just sounds like you have never heard of libtool, which adds most of the stuff in you…

I know all about libtool, thank you, and I'm quite aware that it writes dependency information into its .la files. I use libstool every day. It sucks. This functionality has to be built into the linker.

Re: Dynamic linking

#172

Post by ndesaulniers »

Vogtinator wrote: post #4

> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies. That's correct, but also very misleading and leads to the wrong conclusion. The dynamically linked library has references to itself, externally visible or not. It would be wrong to claim that Application.run(); only uses a single symbol of a library. > A good linker will remove unused symbols. With LTO or -f{fu…

> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies.

For more on this, I highly recommend these two posts, which show how modern symbol tables optimize for symbols NOT being found within a given shared object via the use of bloom filters.

1. https://flapenguin.me/elf-dt-hash

2. https://flapenguin.me/elf-dt-gnu-hash

Re: Dynamic linking

#173

Post by ndesaulniers »

sprash wrote: post #51

Static linking allows LTO with aggressive inlining and is therefore able to achieve far superior performance beyond just the startup time. Arguing that dynamic vs. static has better RAM utilization or not is pointless because nowadays we have plenty of RAM but single core performance is stagnating for almost a decade already. Moores law might give us more transistors but single thread performance is still more or les…

static linking != LTO

LTO requires source, or at least IR.

Static linking involves object files; there's been a loss of fidelity at that point that prevents inlining.

Re: Dynamic linking

#174

Post by ndesaulniers »

cryptonector wrote: post #23

By far the most important reason for dynamic linking for C is semantics: static linking semantics are stuck in 1978 and suck (more on that below), while dynamic linking semantics make C a much better language. In particular, static linking for C has two serious problems: 1. symbol collisions -> accidental interposition (and crashes); 2. you have to flatten the dependency tree into a topological sort at the final link…

> - use of weak symbols to detect whether a process has some library loaded

RTLD_NOLOAD

> Dynamically-linked programs will load faster when their dependencies are already loaded in memory, and slower otherwise. The biggest win here is the C library.

RTLD_LAZY, though it's one less attack vector to have RTLD_NOW and mprotect your GOT and PLT as readonly.

Re: Dynamic linking

#175

Post by mrich »

During development of a large system static linking is hell. The final link just takes too long if you are only working on one object file. Also during debugging you have to load all symbols in gdb, which does not scale. With dynamic linking you only load the debug info for the library you are working on.

Re: Dynamic linking

#176

Post by adrianN »

mrich wrote: post #175

During development of a large system static linking is hell. The final link just takes too long if you are only working on one object file. Also during debugging you have to load all symbols in gdb, which does not scale. With dynamic linking you only load the debug info for the library you are working on.

GDB handles binaries in the hundreds of megabytes fairly well.

Re: Dynamic linking

#177

Post by comex »

saagarjha wrote: post #89

As always, static and dynamic linking both have their advantages and drawbacks. The usual arguments for dynamic linking around brought up in the article, and as others have mentioned here, the analysis is a bit lacking so the conclusions aren't generally true. Static linking has its own, fairly straightforwards benefits as well. It's no surprise that those who push one or the other usually do so because of their spec…

Nitpick: macOS has used dyld shared caches for over a decade. The recent change is just to remove the original copies of the libraries on disk.

Re: Dynamic linking

#178

Post by toast0 »

DSMan195276 wrote: post #129
earthboundkid wrote: post #40

Say we have program X with dependency Y. X+Y is either dynamic or static. X can either have responsive maintainers or unresponsive maintainers. Y can either change to fix a bug or change to add a bug. (With Heartbleed, I remember our server was fine because we were on some ancient version of OpenSSL.) Here are the scenarios: - dynamic responsive remove bug: Positive/neutral. Team X would have done it anyway. - dynami…

> I remember our server was fine because we were on some ancient version of OpenSSL. It's a side point, but I don't entirely understand the argument here since it's basically guaranteed you were vulnerable to a variety of other bugs due to not updating. It depends how old your OpenSSL version was I suppose, but still, it kinda feels like gloating you survived a hurricane by doing no preparation - I'm happy for you, b…

> I remember our server was fine because we were on some ancient version of OpenSSL.

It's a side point, but I don't entirely understand the argument here since it's basically guaranteed you were vulnerable to a variety of other bugs due to not updating. It depends how old your OpenSSL version was I suppose, but still, it kinda feels like gloating you survived a hurricane by doing no preparation - I'm happy for you, but that doesn't necessarily make it a great idea ;)

At the time, I think OpenSSL had several trees that were supported, Heartbleed was in the 1.0.1 tree, but not earlier trees, 1.0.0 and 0.9.8 trees were both still supported. OpenSSL versioning isn't very conventional, so one might not realize that 1.0.1 is a major version difference from 1.0.0, and 1.0.0 is a major version different than 0.9.8, but that's how they roll, minor versions within a series get letters after the name, and sometimes break binary compatibility (ugh). There's a reason a lot of people were slow to update to 1.0.1; unfortunately for me, my company had just updated to 1.0.1 about a month before the bug was reported, so we could get TLS 1.2 support. Would have saved a lot of headache if we had waited :(

Re: Dynamic linking

#179

Post by saagarjha »

comex wrote: post #177
saagarjha wrote: post #89

As always, static and dynamic linking both have their advantages and drawbacks. The usual arguments for dynamic linking around brought up in the article, and as others have mentioned here, the analysis is a bit lacking so the conclusions aren't generally true. Static linking has its own, fairly straightforwards benefits as well. It's no surprise that those who push one or the other usually do so because of their spec…

Nitpick: macOS has used dyld shared caches for over a decade. The recent change is just to remove the original copies of the libraries on disk.

Ah, you're right. Forgot that they were being used already :) I'm curious what would happen though if you modified a system library and didn't update the cache, though…

Re: Dynamic linking

#180

Post by toast0 »

loeg wrote: post #127
pengaru wrote: post #42

Back in the 90s we'd statically link the most frequently executed programs on busy servers for a significant performance boost. Dynamic linking is not a performance feature, it's a decoupling feature.

FreeBSD statically links LLVM into Clang faster build times (2020). (The difference is pretty marginal, but it's at least a percent or two faster.) So my /usr/bin/clang is a 70 megabyte file. The vast majority of the contents are r-x text (code) and r-- read-only data. I don't know if the kernel is capable of sharing read-only paged memory references or not.

> I don't know if the kernel is capable of sharing read-only paged memory references or not.

Any pages mapped from disk should be shared, as a consequence of the FreeBSD unified buffer cache; this is why if you write to a binary in-place with cp instead of unlinking first (like install), currently executing copies are changed, and usually crash :). Read-write program sections will be mapped so their changes are private though, so you get copy on write semantics. Trailing parts that aren't page sized will be copied into a full page, I think.

Post reply on HN