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

81–90 of 249 posts

Re: Dynamic linking

#81

Post by joosters »

Over half of your libraries are used by fewer than 0.1% of your executables

That's a very misleading reference and graph. First of all, what did they expect to find? As you add more executables, of course the % usage of a library will decrease.

e.g. say I have a networking library on my computer, and, in a perfect world, all my installed network tools link against it. But now I install Gnome, and my machine has hundreds more binaries. Not all of the binaries will do networking stuff, so the % usage of the networking library goes down. But that doesn't mean that the networking library is not being shared as well as it could be.

A much better metric would be to count, for each shared library on a machine, the number of programs that link against it. If only one program uses a shared library, then that means the 'shared-ness' is not being used. If more than one program use it, then the library is being effectively shared. But the actual count, whether it is 200 users or 20, doesn't mean anything more. That's why comparing all libraries against libc's usage shows nothing useful.

Re: Dynamic linking

#82

Post by jjoonathan »

joosters wrote: post #81

Over half of your libraries are used by fewer than 0.1% of your executables That's a very misleading reference and graph. First of all, what did they expect to find? As you add more executables, of course the % usage of a library will decrease. e.g. say I have a networking library on my computer, and, in a perfect world, all my installed network tools link against it. But now I install Gnome, and my machine has hundr…

Yeah. Loading the GUI widget toolkit once rather than 30 times is pretty nifty.

Re: Dynamic linking

#83

Post by saagarjha »

wahern wrote: post #3

Do any Linux/glibc or Linux/musl systems support static PIE binaries, yet? Without static PIE support you don't benefit from ASLR (at least not fully). This 2018 article seems like a good breakdown of the issues: https://www.leviathansecurity.com/blog/aslr-protection-for-s... OpenBSD has supported static PIE since 2015; not just supported, but all system static binaries (e.g. /bin and /sbin) are built as static PIEs,…

I'm not sure I understand the first link you posted: if a binary is statically linked, why does it need a GOT? It's literally calling functions in its own binary…

Re: Dynamic linking

#84

Post by yjftsjthsd-h »

a1369209993 wrote: post #76
devit wrote: post #16

Earlier quoted context omitted.

For a useful comparison you need the static and dynamic distributions to be otherwise the same, i.e. you want to pick a mainstream distribution and build it from scratch with both static and dynamic linking and compare.

I don't know of any mainstream distribution that doesn't make full-static-from-scratch builds gratuitously painful and difficult. Personally I gave up after trying to blunt-force-trauma glibc into linking correctly, though, so someone with more internals knowledge might have better success at it.

Depends on your ideas of "mainstream"; I expect nixos and gentoo are both happy to do such rebuilds for you. But, as you note, the real pain is that glibc really doesn't want you to do static builds... I wonder how gentoo and/or nixos support is for musl...

Re: Dynamic linking

#85

Post by IshKebab »

petters wrote: post #52
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…

Sure, but I think the most important reason people have in mind when they argue for dynamic linking is that they will receive upstream bugfixes. I don't think your eight cases are equally important. You are of course right, though, and writing it down like this can be useful.

Why would you not receive upstream bug fixes with statically linked programs? Assuming you are using an Apt-style package manager then the statically linked program would be rebuilt and updated too.

If you are not using an apt-style package manager then the program must include all of its dependencies (except ones that are guaranteed to be present on the platform, which is none on Linux and a few on Mac/Windows), and you will receive bug fixes when that program is updated, whether or not it uses static linking.

Static/dynamic linking does not affect how likely you are to get bug fixes in any way as far as I can tell.

Re: Dynamic linking

#86

Post by cryptonector »

joosters wrote: post #81

Over half of your libraries are used by fewer than 0.1% of your executables That's a very misleading reference and graph. First of all, what did they expect to find? As you add more executables, of course the % usage of a library will decrease. e.g. say I have a networking library on my computer, and, in a perfect world, all my installed network tools link against it. But now I install Gnome, and my machine has hundr…

Even better would be to measure sharing in the totality of programs you use directly and indirectly from boot.

Re: Dynamic linking

#87

Post by yjftsjthsd-h »

mcguire wrote: post #34
pm215 wrote: post #21

I think a more interesting analysis of "security vulnerability costs for static linking" would look not at just "how many bytes does the end user download" but "what are the overall costs to the distro to support a fully statically linked setup", looking at eg CPU costs of doing the rebuild or how much total-elapsed-time it would take to do a full rebuild of every affected package.

Not to mention that fixing a security vulnerability in, say, libm or libc becomes an amount of work equivalent to a distribution upgrade with all the associated risks. Or am I the only one who has occasional problems when replacing all the binaries on my system?

That sounds like a separate issue; normally, having to do a full dist upgrade means that you changed versions of lots of core components (kernel, init, libc, gcc), which is indeed traumatic. If you replace every binary but the only change is bumping the statically-linked libc from x.y.0 to x.y.1, it should be just as boring as making the same change with a dynamically-linked libc.

Re: Dynamic linking

#88

Post by cryptonector »

pengaru wrote: post #69

Static linking has been such a nuisance for the libSDL folks that they implemented dynamic loading of itself [0], controlled via an environment variable, as an escape hatch from executables w/libSDL linked statically. It's understandable that games, especially proprietary ones, distribute statically-linked binaries ensuring any third-party dependencies will be present and be a compatible version. But the value of tha…

> [...] Having said that, I do wish the average linux distro still statically linked everything in /bin and /sbin. It was nice to still be able to administrate the system even when the dynamic libraries were hosed. [...]

This argument came up back when Solaris 10 was in development and the project to get rid of static link archives for system libraries came up (search for Solaris "unified process model"). The disposition of this argument was that if your libraries are damaged (e.g., someone unlinked them or renamed them out of the way, or maybe ld.so.1 itself), well, the dependent utilities in /bin and /sbin themselves could have been damaged too, so you can't know the extent of the damage, and it's not safe to continue -- you have to use boot media to repair the damage, or reinstall. And, of course, the packaging system has to be safe, but that's not a lot to expect of a packaging system (is it??).

To my knowledge there were no subsequent customer calls about this.

Re: Dynamic linking

#89

Post by saagarjha »

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 specific needs. Sometimes we even see some interesting hybrid solutions: one recent one is Apple introducing dyld shared caches on macOS, which (while being a pain to reverse engineer) are basically all the system (dynamic) libraries all statically linked together and presented dynamically, with some linker tricks to make it appear seamless. Likewise, a lot of statically linked binaries are only partially statically linked, still using things like libc or graphics libraries. The moral really is to try both and pick whichever one is the one that's better for your use case, and perhaps even consider a mix of both to give you the most flexibility in which tradeoffs you'd like to make.

Re: Dynamic linking

#90

Post by andyjpb »

This is an interesting analysis. For my part (anecdata), in my /usr/bin (Debian) I have 2,956 files under 9MiB in size, 1 of 13MiB and one of 39MiB. Most of the files are (much) under 1.0MiB.

On the other hand, I have a three statically linked binaries for CloudFoundry in my home directory. One for Linux, one for MacOS and one for Windows. They are each between 24MiB and 27MiB each.

Post reply on HN