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

201–210 of 249 posts

Re: Dynamic linking

#201

Post by saagarjha »

jart wrote: post #111
andoma wrote: post #26

Earlier quoted context omitted.

In theory yes. However, in practice static linking with glibc pulls in a lot of dead weight, musl comes to the rescue though: test.c: int main(int argc, char **argv) { printf("hello world\n"); return 0; } Dynamic linking (glibc): $ gcc -O2 -Wl,--strip-all test.c $ ls -sh a.out 8.0K a.out Static linking (glibc): $ gcc -O2 --static -Wl,--strip-all test.c $ ls -l a.out 760K a.out Static linking (musl): $ musl-gcc --stat…

Static linking ( https://github.com/jart/cosmopolitan ) jart@debian:~/cosmo$ make -j12 CPPFLAGS+=-DIM_FEELING_NAUGHTY MODE=tiny o/tiny/examples/hello.com jart@debian:~/cosmo$ ls -sh o/tiny/examples/hello.com 20K o/tiny/examples/hello.com Note: Output binary runs on Windows, Mac, and BSD too.

I hope you can forgive me for asking, but what exactly is this (cosmopolitan)? It looks interesting but I can’t really tell what it’s trying to be.

Re: Dynamic linking

#202

Post by IshKebab »

saagarjha wrote: post #91
IshKebab wrote: post #85

Earlier quoted context omitted.

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…

The first hurdle is that you require source code to do any of this. Then you need to actually rebuild everything.

Apt-style package systems do have source for everything and rebuild everything.

Re: Dynamic linking

#203

Post by nabla9 »

Would this distinction would go largely away if OS would have method to share read only memory pages or larger regions of memory between all processes?

I suspect you would need to compute signatures for static libraries for binaries located /bin/, /lib, ... to make load times faster.

Re: Dynamic linking

#204

Post by enriquto »

Static executables are a sweet spot between the craziness of dynamic dependencies (where we come from) and the idiocy of shipping a whole virtual machine for each program (where we seem to be going to). If we could just stop at that spot!

Re: Dynamic linking

#205

Post by adev_ »

microtonal wrote: post #194
tsimionescu wrote: post #187

Earlier quoted context omitted.

I was talking about finding vulnerabilities on end-user systems and servers. I don't know about others, but I don't generally keep compiler tool chains for C, C++, Java, Go and maybe 1-2 others on my systems and on my servers in case I need to rebuild all of my binaries.

I was talking about finding vulnerabilities on end-user systems and servers. I don't know about others, but I don't generally keep compiler tool chains [...] You don't have to, most NixOS/Guix systems use binary caches. So, their build clusters do the work for the packages included the nixpkgs/guix package sets. If your organization builds their own packages in top of that, you can use a CI plus your private cache (o…

> You don't have to, most NixOS/Guix systems use binary caches.

Yes, Nix/Guix and Spack are up to my knowledge the only systems that got that right. The centralised recipe repository (and their functional nature) make scratch recompilation reliable and easy.

Now good luck to get that with most lock-file based package managers like npm, cargo or pip with ~1000 packages in your dependency tree that hardcode their dependency number...

The distributed approach of some package manager often come with a security cost unfortunately. And that's a problem for static linking.

Re: Dynamic linking

#206

Post by pjmlp »

cosmojg wrote: post #149
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,…

> but the basic takeaway is that dynamic linking in system toolchains and system runtimes is far more mature than static linking. But that's a chicken-or-egg problem, right? The only way static linking tools will reach parity with dynamic ones in terms of maturity is if static linking replaces dynamic linking as the de facto method of choice.

Generally speaking static compilation has had 30 years of head start across multiple OS and hardware architectures, until dynamic compilation was even an option on mainstream computing, it was after all the only way, with dynamic only available in research platforms like what was going on at Xerox PARC.

So this widespread lack of knowledge that static is actually more mature than dynamic is kind of ironic.

Re: Dynamic linking

#207

Post by pjmlp »

vlovich123 wrote: post #142
zelly wrote: post #112

Dynamic linking provides encapsulation and security benefits. An application with a statically linked OpenSSL can be vulnerable if a CVE comes out for that version of OpenSSL, whereas a dynamically linked OpenSSL could be patched immediately without recompilation (which may be impossible if the software is proprietary). The vendor of the shared library can update the implementation without requiring all downstream co…

From distributions where you build everything from source (most cloud providers today, mobile phone operators, etc), such advantages are purely theoretical & never play out in practice. In such environments you're pushing out updates of the entire system on whatever your regular cadence is. Additionally, because the old library is still mapped & running you have to know to restart all the processes that have the old…

Where are those mobile phone operators building everything from scratch?

Because from my telecommunications and mobile OS development knowledge I have hard time remembering at least one.

And binary deployments? They are done all the time.

Re: Dynamic linking

#208

Post by pjmlp »

tannhaeuser wrote: post #192
setr wrote: post #24

I believe the original reasoning for Dynamic Linking wasn't performance gains, but security gains -- someone described the driving story to me as essentially a found vulnerability in a very common library required updating and re-compiling everything on every system , scarring sysadmins globally and permanently; the space saving and performance aspects came up as later "bonuses". I have little memory of the details o…

Don't forget that the principles of the LGPL (originally the "library GPL") were/are pretty much tied to the technical concept of a shared library object that an end-user can change, etc; IANAL so I can't say anything about the legal soundness of this interpretation. Moreover, in a recent discussion about this topic on HN, someone said the introduction of shared libs into the Linux user space was mainly in support of…

Without shared libraries, the only way to do plugins is via IPC.

Sure it is more secure and probably preferable in modern times, but it also slower and requires more hardware resources, specially when one scales it with desktop software running hundreds of processes, each for their own plugin sets.

There is no free lunch as they say.

Re: Dynamic linking

#209

Post by pjmlp »

kortex wrote: post #163
gok wrote: post #67

Why stop there? Package every binary in its own container, too! Most programs only use a few system calls, so you're not really getting anything by sharing a single kernel for the entire system.

That's literally what RancherOS does. ls is a container. Blew my mind the first time I saw it. But they take the "cattle not pets" approach pretty much to its logical extreme (I suspect that the company's name arises from this metaphor) It makes ops so liquid and convenient. I love it. To really push this idea (and microkernel) to its logical extreme, it would be cool to see a null-kernel. You have socket drivers, th…

It makes sense from security point of view, but it definitely is much more resource intensive.

Imagine something like InteliJ or Eclipse, where every single IDE plugin is its own process doing IPC.

Re: Dynamic linking

#210

Post by marcthe12 »

yjftsjthsd-h wrote: post #84
a1369209993 wrote: post #76

Earlier quoted context omitted.

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...

You going to have to disable PAM which basically limits the the stuff you can install. Also qt and Mesa are designed to be static libs so expect token stuff. I have some ideas to solve thisfor long time but any solution is going by in from multiple places.
Post reply on HN