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

61–70 of 136 posts

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

#61

Post by greenavocado »

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…

> Do people really not know about $OBSCURE_GCC_FLAG?

Do you know what you sound like?

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

#62

Post by TuxSH »

pjmlp wrote: post #53
TuxSH wrote: post #50

Earlier quoted context omitted.

> How can they be expected to learn this It's the first thing Google and LLMs 'tell' you when you ask about reducing binary size with static libraries. Also LTO does most of the same.

To learn, first one needs to want to learn, which was my whole point.

Agreed, but article's author mentioned this as an issue, I would have expected him to find about and mention these flags as well.

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

#63

Post by adev_ »

high_na_euv wrote: post #48
adev_ wrote: post #47

Earlier quoted context omitted.

> Why things that are solved in other programming ecosystems are impossible in c cpp world, like sane building system This is such an ignorant comment. Most other natively compiled languages have exactly the same concept behind: Object files, Shared Libraries, collection of object and some kind of configuration description of the compilation pipeline. Even high level languages like Rust has that (to some extend). The…

>The fact you (probably) never had to manipulate it directly just mean your higher level work never brought you deep enough where it starts to be a problem. Did you just agree with me that other prog. ecosystems solved the building system challenge?

> Did you just agree with me that other prog. ecosystems solved the building system challenge?

Putting the crap is a box with a user friendly handle on it to make it look 'friendlier' is never 'solving a problem'.

It is barely hiding the dust under the carpet.

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

#64

Post by kazinator »

.a archives can speed up linking of very large software. This is because of assumptions as to the dependencies and the way the traditional Unix-style linker deals with .a files (by default).

When a bunch of .o files are presented to the linker, it has to consider references in every direction. The last .o file could have references to the first one, and the reverse could be true.

This is not so for .a files. Every successive .a archive presented on the linker command line in left-to-right order is assumed to satisfy references only in material to the left of it. There cannot be circular dependencies among .a files and they have to be presented in topologically sorted order. If libfoo.a depends on libbar.a then libfoo.a must be first, then libbar.a.

(The GNU Linker has options to override this: you can demarcate a sequence of archives as a group in which mutual references are considered.)

This property of archives (or of the way they are treated by linking) is useful enough that at some point when the Linux kernel reached a certain size and complexity, its build was broken into archive files. This reduced the memory and time needed for linking it.

Before that, Linux was linked as a list of .o files, same as most programs.

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

#65

Post by asveikau »

pjmlp wrote: post #42
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…

How can they be expected to learn this, when it is now fashionable to treat C and C++ as if they are scripting languages, shipping header only files? We already had scripting engines for those languages in the 1990's, and the fact they are hardly available nowadays kind of tells of their commercial success, with exception of ROOT.

It makes more sense for c++ due to templates, but the header only C library trend is indeed very strange. It's not surprising that people are coming up now who are writing articles about being confused by static linking behavior.

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

#66

Post by Brian_K_White »

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…

You act as though the sales pitch for dynamically loaded shared libs is the whole story.

Obviously everything has some reason it was ever invented, and so there is a reason dynamic linking was invented too, and so congratulations, you have recited that reason.

A trivial and immediate counter example though is that a hacker is able to replace your awesome updated library just as easily with their own holed one, because it is loaded on the fly at run-time and the loading mechanism has lots of configurability and lots of attack surface. It actually enables attacks that wouldn't otherwise exist.

And a self contained object is inherently more portable than one with dependencies that might be either missing or incorrect at run time.

There is no simple single best idea for anything. There are various ideas with their various advantages and disadvantages, and you use whichever best services your priorities of the moment. The advantages of dynamic libs and the advantages of static both exist and sometimes you want one and sometimes you want the other.

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

#68

Post by [deleted] »

greenavocado wrote: post #61
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…

> Do people really not know about $OBSCURE_GCC_FLAG? Do you know what you sound like?

[deleted]

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

#69

Post by lokar »

amiga386 wrote: post #5

> Yet, what if the logger’s ctor function is implemented in a different object file? This is a contrived example akin to "what if I only know the name of the function at runtime and have to dlsym()"? Have a macro that "enables use of" the logger that the API user must place in global scope, so it can write "extern ctor_name;". Or have library specific additions for LDFLAGS to add --undefined=ctor_name There are worka…

Also, don’t use automatic module init, make the user call an init function at startup.

And prefix everything in your library with a unique string.

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

#70

Post by cryptonector »

It's not that .a files and static linking are a relic, but that static linking never evolved like dynamic linking did. Static linking is stuck with 1978 semantics, while dynamic linking has grown features that prevent the mess that static linking made. There are legit reasons for wanting static linking in 2025, so we really ought to evolve static linking like we did dynamic linking.

Namely we should:

  - make -l and -rpath options in
    .a generation do something:
    record that metadata in the .a

  - make link-edits use that meta-
    data recorded in .a files in
    the previous item
I.e., start recording dependency metadata in .a files and / so we can stop flattening dependency trees onto the final link-edit.

This will allow static linking to have the same symbol conflict resolution behaviors as dynamic linking.

Post reply on HN