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

The .a file is a relic: Why static archives were a bad idea all along

medium.com

Post reply on HN
Print view View original

31–40 of 136 posts

Re: The .a file is a relic: Why static archives were a bad idea all along

#31

Post by alexvitkov »

EE84M3i wrote: post #26
LtWorf wrote: post #23

Earlier quoted context omitted.

You can, but why?

At a fundamental level I don't understand why we have two separate file types for static and dynamic libraries. It seems primarily for historical reasons? The author proposes introducing a new kind of file that solves some of the problems with .a filed - but we already have a perfectly good compiled library format for shared libraries! So why can't we make gcc sufficiently smart to allow linking against those statica…

Because with the current compilation model shared libraries (.so/.dll) are the output of the linker, but static libraries are input for the linker. It is historical baggage, but as it currently stands they're fairly different beasts.

Re: The .a file is a relic: Why static archives were a bad idea all along

#32

Post by Joker_vD »

EE84M3i wrote: post #26
LtWorf wrote: post #23

Earlier quoted context omitted.

You can, but why?

At a fundamental level I don't understand why we have two separate file types for static and dynamic libraries. It seems primarily for historical reasons? The author proposes introducing a new kind of file that solves some of the problems with .a filed - but we already have a perfectly good compiled library format for shared libraries! So why can't we make gcc sufficiently smart to allow linking against those statica…

Oh, it's even better on the Windows side of things, at least how the MSVC toolchain does it. You can only link a statically-linked .lib library, period. So if you want to statically link against a dynamic library (what a phrase!), you need to have a special version of that .lib library that essentially is just a collection of thunks (in MSVC-specific format) that basically say "oh, you actually want to add symbol Bar@8 from LIBFOO.DLL to your import section" [0]. So yeah, you'd see three binaries distributed as a result of building a library: libfoo_static.lib (statically-linked library), libfoo.dll (dynamic library), libfoo.lib (the shim library to link against when you want to link to libfoo.dll).

Amusingly, other (even MSVC-compatible) toolchains never had such problem; e.g. Delphi could straight up link against a DLL you tell it to use.

[0] https://learn.microsoft.com/en-us/cpp/build/reference/using-...

Re: The .a file is a relic: Why static archives were a bad idea all along

#34

Post by alexvitkov »

tempay wrote: post #30
alexvitkov wrote: post #29

Earlier quoted context omitted.

Because I want my program to run on other people's computers.

I think the question isn’t why statically link but rather why bother with .a files and instead use the shared libraries all the time (even if only to build a statically linked executable).

Yeah, I misunderstood the question. Although if you could statically link .so/.dlls and have it work reliably, it would still be a great convenience, as some libraries are really hard to build statically without rewriting half their build system.

Re: The .a file is a relic: Why static archives were a bad idea all along

#35

Post by [deleted] »

TuxSH wrote: post #11

> This design decision at the source level, means that in our linked binary we might not have the logic for the 3DES building block, but we would still have unused decryption functions for AES256. Do people really not know about `-ffunction-sections -fdata-sections` & `-Wl,--gc-sections` (doesn't require LTO)? Why is it used so little when doing statically-linked builds? > Let’s say someone in our library designed th…

[deleted]

Re: The .a file is a relic: Why static archives were a bad idea all along

#36

Post by benreesman »

sp1rit wrote: post #25
benreesman wrote: post #8

It is unclear to me what the author's point is. Its seems to center on the example of DPDK being difficult to link (and it is a bear, I've done it recently). But its full of strawmen and falsehoods, the most notable being the claims about the deficienies of pkg-config. pkg-config works great, it is just very rarely produced correctly by CMake. I have tooling and a growing set of libraries that I'll probably open sour…

> Static libraries have lots of game-changing advantages, but performance, security, and portability are the biggest ones. No idea how you come to that conclusion, as they are definitively no more secure than shared libraries. Rather the opposite is true, given that you (as end user) are usually able to replace a shared library with a newer version, in order to fix security issues. Better portability is also question…

Knowing what code runs when i invoke an executable or grant it permissions is a fucking prerequisite for any kind of fucking security.

Portability is to any fucking kernel in a decade at the ABI level. You dont sound stupid, which means youre being dishonest. Take it somewhere else before this gets okd school Linus.

I have no fucking patience when it comes to eirher Drepper and his goons or the useful idiots parroting that tripe at the expense of less technical people.

edit: I don't like losing my temper anywhere, especially in a community where I go way back. I'd like to clarify that I see this very much in terms of people with power (technical sophistication) and their relationship to people who are more vulnerable (those lacking that sophistication) in matters of extremely high stakes. The stakes at the low end are the cost and availability of computing. The high end is as much oppressive regime warrantless wiretap Gestapo shit as you want to think about.

Hackers have a responsibility to those less technical.

Re: The .a file is a relic: Why static archives were a bad idea all along

#37

Post by astrobe_ »

TuxSH wrote: post #11

> This design decision at the source level, means that in our linked binary we might not have the logic for the 3DES building block, but we would still have unused decryption functions for AES256. Do people really not know about `-ffunction-sections -fdata-sections` & `-Wl,--gc-sections` (doesn't require LTO)? Why is it used so little when doing statically-linked builds? > Let’s say someone in our library designed th…

Yes, these are really esoteric options, and IIRC GCC's docs say they can be counter-productive.

Re: The .a file is a relic: Why static archives were a bad idea all along

#38

Post by jeffbee »

astrobe_ wrote: post #37
TuxSH wrote: post #11

> This design decision at the source level, means that in our linked binary we might not have the logic for the 3DES building block, but we would still have unused decryption functions for AES256. Do people really not know about `-ffunction-sections -fdata-sections` & `-Wl,--gc-sections` (doesn't require LTO)? Why is it used so little when doing statically-linked builds? > Let’s say someone in our library designed th…

Yes, these are really esoteric options, and IIRC GCC's docs say they can be counter-productive.

-ffunction-sections has 750k hits on github. It is among the default flags for opt mode builds in Bazel. There are probably people who consider them defaults, in practice.

Re: The .a file is a relic: Why static archives were a bad idea all along

#39

Post by benreesman »

ethin wrote: post #24
benreesman wrote: post #8

It is unclear to me what the author's point is. Its seems to center on the example of DPDK being difficult to link (and it is a bear, I've done it recently). But its full of strawmen and falsehoods, the most notable being the claims about the deficienies of pkg-config. pkg-config works great, it is just very rarely produced correctly by CMake. I have tooling and a growing set of libraries that I'll probably open sour…

The only exception to this general rule (which, to be clear, I agree with) is when your code for whatever links to LGPL licensed code. A project I'm a major contributor of does this (we have no choice but to use these libraries, due to the requirements we have, though we do it via implib.so (well, okay, the plan is to do that)), and so dynamic linking/DLL hell is the only path we are able to take. If we link statical…

Sure, there are use cases. Extensions to e.g. Python are a perfectly reasonable usecase for `dlopen` (hooking DNS on all modern Linux is...probably not for our benefit).

There are use cases for dynamic linking. It's just user-hostile as a mandatory default for a bunch of boring and banal reasons: KitWare doesn't want `pkg-config` to work because who would use CMake if they had straightforward alternatives. The Docker Industrial complex has no reason to exist in a world where Linus has been holding the line of ABI compatibility for 30 years.

Dynamic linking is fine as an option, I think it's very reasonable to ship a `.so` alongside `.a` and other artifacts.

Forcing it on everyone by keeping `pkg-config` and `musl` broken is a more costly own goal for computing that Tony Hoare's famous billion dollar mistake.

Re: The .a file is a relic: Why static archives were a bad idea all along

#40

Post by l72 »

sp1rit wrote: post #25
benreesman wrote: post #8

It is unclear to me what the author's point is. Its seems to center on the example of DPDK being difficult to link (and it is a bear, I've done it recently). But its full of strawmen and falsehoods, the most notable being the claims about the deficienies of pkg-config. pkg-config works great, it is just very rarely produced correctly by CMake. I have tooling and a growing set of libraries that I'll probably open sour…

> Static libraries have lots of game-changing advantages, but performance, security, and portability are the biggest ones. No idea how you come to that conclusion, as they are definitively no more secure than shared libraries. Rather the opposite is true, given that you (as end user) are usually able to replace a shared library with a newer version, in order to fix security issues. Better portability is also question…

I think from a security point of view, if a program is linked to its library dynamically, a malicious actor could replace the original library without the user noticing, by just setting the LD_LIBRARY_PATH to point to the malicious library. That wouldn't be possible with a program that is statically linked.
Post reply on HN