Do people who write this kind of pieces with such peremptory titles really believe that they finally came about to understand everything better after decades of ignorance? Chesterton’s Fence yada yada?
Well, it is on medium.com, so probably yes?
The .a file is a relic: Why static archives were a bad idea all along
71–80 of 136 posts
Re: The .a file is a relic: Why static archives were a bad idea all along
#72It 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…
pkg-config works great in limited scenarios. If you try to do anything more complex, you'll probably run into some complex issues that require modifying the supplied .pc files from your vendor.
There's is a new standard that is being developed by some industry experts that is aiming to address this called CPS. You can read the documentation on the website: https://cps-org.github.io/cps/ . There's a section with some examples as to why they are trying to fix and how.
Re: The .a file is a relic: Why static archives were a bad idea all along
#73Something I've never quite understood is why can't you statically link against an so file? What specific information was lost during the linking phase to create the shared object that presents that machine code from being placed into a PIE executable?
so files require PIC code, which brings along symbol interpolation.
Re: The .a file is a relic: Why static archives were a bad idea all along
#74Earlier 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…
you could say historical reasons, in that dynamic libraries are generated using relocatable position independent code (-pic), which incurs some performance penalty vs code where the linker fills in all the relocations. my guess is thats somewhere around 10%? historical in the sense that that used to be enough to matter? idk that it still is
personally I think leaving the binding of libraries to runtime opens up alot of room for problems, and maybe the savings of having a single copy of a library loaded into memory vs N specialized copies isn't important anymore either.
Re: The .a file is a relic: Why static archives were a bad idea all along
#75Library files are not the problem, deploying an SDK as precompiled binary blobs is ;)
(I bet that .a/.lib files were originally never really meant for software distribution, but only as intermediate file format between a compiler and linker, both running as part of the same build process)
Re: The .a file is a relic: Why static archives were a bad idea all along
#76> 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…
There's also the other 'old-school' method to compile each function into its own object file, I guess that's why MUSL has each function in its own source file:
https://github.com/kraj/musl/tree/kraj/master/src/stdio
...but these days -flto is simply the better option to get rid of unused code and data - and enable more optimizations on top. LTO is also exactly why static linking is strictly better than dynamic linking, unless dynamic linking is absolutely required (for instance at the operating system boundary).
Re: The .a file is a relic: Why static archives were a bad idea all along
#77> 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.
An STB-style header-only library is actually quite perfect for eliminating dead code if the implementation and all code using that library is in the same compilation unit (since the compiler will not include static functions into the build that are not called).
...or build -flto for the 'modern' catch-all feature to eliminate any dead code.
...apart from that, none of the problems outlined in the blog post apply to header only libraries anyway since they are not distributed as precompiled binaries.
Re: The .a file is a relic: Why static archives were a bad idea all along
#78Earlier quoted context omitted.
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.
Even with C++ templates, if you want faster builds, header files aren't the place to store external templates, which are instantiations for common type parameters.
Re: The .a file is a relic: Why static archives were a bad idea all along
#79Earlier quoted context omitted.
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.
Header-only is simpler to integrate, so it makes sense for simple stuff, or stuff that is going to be used by only one TU there.
However, the semantics of inline are different between C and C++. To put it simply, C is restricted to static inline and, for variables, static const, whereas C++ has no such limitations (making them a superset); and static inline/const can sometimes lead to binary size bloat
Re: The .a file is a relic: Why static archives were a bad idea all along
#80Something I've never quite understood is why can't you statically link against an so file? What specific information was lost during the linking phase to create the shared object that presents that machine code from being placed into a PIE executable?
I had this exact question a few months back - https://news.ycombinator.com/item?id=44084781