How did things get this bad? The Axioms of linking (2019)
rosshemsley.co.uk
rosshemsley.co.uk
I've never seen a widely used header-only C Lucas library, and while it wouldn't surprise me, it seems harder to justify.
And CMake will take care of transitive dependencies for static libraries for you. Just declare it as a PUBLIC link dependency and all downstream projects will link against it automatically.
What the article fails to mention is that dynamic libraries can also be an attack vector. Users can replace a .so with a variant that does something you don't expect. For statically linked apps, it is much easier to ensure your code has not been tampered with.
Also, the CMake integration in CLion is great. "How did things get this bad?" What are you talking about? It's a great time to be a C++ programmer! The tools are finally stable and powerful (and not either MSVC or ICC) and there's lots of good libraries to choose from.
This assumes that everything is correctly expressed as part of the CMake system. If you stick everything in one build system, of course it’s going to be fine.
> Users can replace a .so with a variant that does something you don't expect. For statically linked apps, it is much easier to ensure your code has not been tampered with.
If your users are able to replace libraries, it’s reasonable to assume that they can mess with the code inside your application too. It is generally hard to ensure your code hasn’t been tampered with, unless you’re in control of the hardware.
I think like most things C++, the modern solutions are great, but a large number of programmers are still stuck with legacy systems that they cannot or will not change for a variety of reasons.
I don't think there is a magic bullet for people experiencing these problems in legacy codebases - it's either update to a more modern build system and use libraries within that ecosystem, or learn how to work around the potential issues outlined in the original article.
My friend who is a music producer has a saying: "You can't polish a turd."
With C++ and CMake, this is apt.
Dynamic linking — on Linux — isn't intended to work on its own. There's a system around it, notably with a package manager and its dependency handling. It's only a component of the larger system, and it's failing because other pieces are just straight-up missing.
No, you can't build on one OS platform, transfer the executable to another, and expect it to work. Yes, other systems (notably Windows, but also Solaris and to some degree the BSDs) make that guarantee, but Linux doesn't. That's just how it is, and it's different across systems, and you need to drop that expectation. For comparison, on OpenBSD you can't link statically (not across OpenBSD versions at least) because syscalls are not an ABI. You need the system's libc, matching the kernel. (cf. recent Go story) Platforms have their own rules. Learn them.
The package manager is also what will fix some of the not-quite-linking-related problems the post cites. Headers and #defines matching the library version — you get that from the package manager's build dependencies. It'll also apply compiler & linker flags that match the platform.
But the most disingenious part of the article is this:
> If you want to move a binary from one machine (where it was compiled) to another
No. You're not moving a binary from one machine to another. You're moving it from one platform to another. Because if the machines have the same platform, it actually works.
To me it feels like the old ways (dynamic linking to system vendored libraries with dependency handling using a package manager) are being lost and the newer methods lose something of the simplicity and beauty of those approaches. I realize that's just my own emotional reaction to it, without any logical justification, but I just wanted to say that.
It is perfectly all right on macOS to statically link your own stuff, or other peoples' stuff. Apple even recommend in a WWDC video that you do it with OpenSSL if you absolutely must use that instead of the framework they provide. (The stated reason is that the OpenSSL API is not stable.)
Like almost every other system except for Linux, it is not perfectly all right to statically link against the C runtime, because that’s what knows how to do system calls. But neither is it ever a problem to dynamically link against it, since it will be kept up to date by system updates. Any normal C++ program will dynamically link against libc++ and libSystem in /usr/lib.
Apple packages its APIs as "Frameworks", and a normal application will dynamically link against those.
However, one Linux tip: .a files aren't magic, they're actually just an 'ar' archive, and in some cases you can use this to combine existing .a files together if you want to for some reason.
Semi-related, environment variables are pure evil. Operating systems shouldn’t allow environment variables and programming languages shouldn’t allow global variables.
C++ headers are insane and miserable. Makes me sad. And causing me endless grief.
One distinction the author doesn’t quite make (unless I missed it) is the difference in shipping a pre-compiled static lib and shipping code intended to be compiled in a static lib. The first is almost the same thing as shipping a shared lib. You need a pure C API to ensure compatibility. The second you can do whatever because users will compile with their own settings and types will be consistent.
Defending absolutist opinions is usually difficult and I this one is no different. What do you have against environment variables, which provide a unified interface to expose user-facing tunables? Where do you store shared program state?
The alternative? Users launching a program should explicitly specify configuration information. Choose sane defaults. Let them be configurable via cmdline args or a config file. Ideally both. An explicitly specified config file is so much cleaner than envvar imho. Scripts that locally override global envvar is super sketch, hidden, and error prone.
TBH I think the fact that Docker exists is testament to the INSANITY of Linux environment configuration. It’s so incredibly hard to reliably launch a program that we built ecosystems of containers to encapsulate system wide configuration. And even that is hard and error prone.
This is just silly.
Global state is inevitable. If it's not in the environment it would be in the filesystem or the Windows registry.
Global state may be inevitable. But that doesn’t mean you should throw the towel and sprinkle global state all over the place. You should try really really hard to have the barest minimum global state. You might be surprised how little you actually need.
Admittedly, that is a bad design, and it is a problem in large part because it is a bad design and not because of using environment variables by itself. In general, though, my preference is that environment variables be the last resort of the programmer for configuration. Providing command-line switches or files in well-known locations is almost always a better idea, and environment variables should largely be reserved only for when the use is of a debugging or other unusual configuration.