Allthough if we’re to keep the cadence, the next harmful consideration is due in September 2036 or something.

We need a British person beyond that point. Because we all know that they have a good feeling for overdoing jokes to the point where they get funny again.

I would argue that it is still only one of numbers.

I have been working for a long time on an OS that has some users, though likely not in the millions. It’s pretty rare that anything is as simple an issue as you’re making this out to be.

I think this period should be 10-15 years. If software has not been updated in that time, then it really should only be run on old versions of the OS anyway, in my opinion.

Maybe? Our (dynamically linked) ABI has been sufficiently backwards compatible that I can still run binaries from 2006 (15 years ago) without recompiling. I suspect I can probably run binaries from earlier than that as well, but that’s your 15 years and it’s also the oldest binary I can see in $HOME/bin right now. Pushing people to rebuild their software puts them on a treadmill of busy work at some frequency, and that doesn’t feel like it adds a tremendous amount of value. At some point clearly you can draw the line; e.g., it will likely not be possible for existing 32-bit binaries to be 2038 safe in any sense, for the obvious reasons about integer width. Because these binaries are only built against dynamic libraries with stable sonames and library versions (not the same as symbol versions), and don’t directly encode any system call specifics or other internals, we have at least a tractable, if not easy, time of making this promise.

I have heard the noisy trumpeting of the static linking people for a pretty long time now, and it just doesn’t speak to me at all. It’s not like I hate them, I just don’t really share or even viscerally appreciate the problem they claim I must have, because I link a lot of software dynamically. There are, of course, exceptions!

I agree that libraries like OpenSSL have, especially in the not-that-distant past, presented a capriciously moving target, both at the ABI level and even at the source compatibility level. That’s not really anything to do with dynamic (or static) linking, though, it’s a question of what the people who work on that project value – and it was, at least historically, not stable interfaces really at all.

As we do a lot of our “linking” nowadays not merely statically or dynamically through ELF, but increasingly through IPC (e.g., sigh, D-Bus) and RPC (e.g., REST), the question of interface stability is the interesting part to me, rather than the specific calling mechanism. Once I put software together I’d really rather spend the minimum amount of time keeping it working in the future. Many, many software projects today don’t value stability, so they just don’t have it.

But some projects do value stability – and thus, in my estimation, the time and energy of their consumers and community – and so I try my level best to depend only on those bodies of software. Dynamic linking just isn’t the problem I have.

To update: I was not able to get prelinking to work, so I put a note in instead.

But I also had an implied argument there: that static linking is easiest for downstream developers. It’s implied because people usually gravitate to what’s easiest.

There was an article on here or the other website recently about people’s focus on what is easiest for developers. I personally think that we should be looking at what’s best for users not what’s easiest for developers.

I apologize that it took so long to get there; that’s how it flowed in my mind. Should I have put them first?

No, I just meant I read dozens of these “dynamic linking bad” articles which complain about dynamic linking and tout the benefits of static linking as if there were literally no benefits to dynamic linking (usually after claiming that because 90% of libraries aren’t shared as much as 10% that means we should ditch 100% of dynamic linking). This was also the vibe of your original article (and a similar vibe of the “static linking considered harmful” article except in the opposite direction).

The problem is that while yes, on the face of it you could say that static linking as things currently stand is less of a shit show, nobody seemed to acknowledge that it might be worth trying to solve the problem in a way which keeps some of the key benefits of dynamic linking. Your article is the first I’ve read so far which actually took this into consideration. That’s why I said I finally have read an article which covers these things.

Is this automatic? Should it be automatic?

It’s not so easy to automate these things portably. I have not looked into automating it but at the same time I almost never write libraries (my opinion is on the other extreme from npm proponents, don’t write a library unless you’ve already written similar code in a number of places and know what the API should look like from real experience).

I kind of think I know what you’re going at here, and I think it’s about the same thing that gcc and other C compilers do for functions with static visibility. So in my language, any functions and types private to a package would be treated as though they have static visibility.

I think that would be sufficient because I think the problem C has is that something does not have static visibility unless you mark it so, leading to a lot of functions that should be static polluting the namespace.

I’m not entirely sure, so what do you think?

Fundamentally the problem is that in C and C++ to get a static library on linux you compile your code into object files and then you put them into an weird crusty old archive format. At the end of the day, unlike with a shared object, you can’t mark symbols as being local to the library since when it comes to linking, it’s as if you had directly added the list of object files to the linking command.

Let me give you an example:

==> build <==
#!/bin/sh -ex
cc -std=c11 -c lib.c
cc -std=c11 -c internal.c
ar rc lib.a lib.o internal.o
ranlib lib.a
cc -shared lib.o internal.o -o liblib.so
cc -std=c11 -I. -c prog.c
cc prog.o lib.a -o prog_static
cc prog.o -L. -llib -Wl,-rpath=. -o prog_dynamic

==> clean <==
#!/bin/sh
rm -f *.o *.a *.so prog_*

==> internal.c <==
#include "internal.h"
#include <stdio.h>
void print(const char *message)
{
	puts(message);
}

==> internal.h <==
#ifndef INTERNAL_H
#define INTERNAL_H
__attribute__ ((visibility ("hidden")))
void print(const char *message);
#endif

==> lib.c <==
#include "lib.h"
#include "internal.h"
__attribute__ ((visibility ("default")))
void api(void)
{
	print("api");
}

==> lib.h <==
#ifndef LIB_H
#define LIB_H
__attribute__ ((visibility ("default")))
void api(void);
#endif

==> prog.c <==
#include <lib.h>
int main(void)
{
	api();
	extern void print(const char *message);
	print("main");
}

In the above example, lib.h exposes an API, this consists of the function api. internal.h is internal to the library and exposes a function print. The visibility has been marked but from the point of view of the linker, linking prog_static from prog.o and lib.a is equivalent to linking prog.o, lib.o and internal.o. This means the linking succeeds and print can be called from main. In the library case, the linking step happens first, the visibilities are honored and once you try to link to the library the print function is no longer exposed.

There is no way to hide the print function in this case. And given how internal functions usually don’t have namespaced names, they have a higher chance of colliding. The solution would be to replace internal.h with the following:

#ifndef INTERNAL_H
#define INTERNAL_H
#define print lib_internal_print
__attribute__ ((visibility ("hidden")))
void print(const char *message);
#endif

(Or something similar like #define print print_3b48214e)

This would namespace the function without having the entire codebase end up having to call the function by the long name.

But this is all hacks, and doesn’t solve the visibility problem.

I hope you see what I mean now.

I’ll bite. I have written a MC6809 emulator that makes the following assumptions of the host system:

• A machine with 8-bit chars (in that it does support uint8_t)

• A 2’s complement architecture

I also do the whole #ifdef __BIG_ENDIAN__ (effectively), check out the header file. How would you modify the code? It’s written that way to a) make it easier on me to understand the code and b) make it a bit more performant.

As the person responsible for making Go able to link to system libraries in the first places (on illumos/Solaris, others later used this technology for OpenBSD, AIX and other systems), I am baffled why people have trouble understanding this.

Go binaries, just like any other userspace binary depend at least on the operating system. “Zero dependency” means binaries don’t require other dependencies other than the system itself. It doesn’t mean that the dependency to the system cannot use dynamic linking.

On systems where “the system” is defined by libc or its equivalent shared library, like Solaris, Windows, OpenBSD, possibly others, the fact that Go binares are dynamically linked with the system libraries doesn’t make them not “zero dependency”. The system libraries are provided by the system!

Also note that on systems that use a shared library interface, Go doesn’t require the presence of the target shared library at build time, only compiled binaries require it at run time. Cross-compiling works without having to have access to target system libraries. In other words, all this is an implementation detail with no visible effect to Go users, but somehow many Go users think this is some kind of a problem. It’s not.

I (clarified) was thinking about e.g. OpenBSD, not Linux; see e.g. cks’ article.

Under some circumstances Go will still link to libc. The net and os packages both use libc for some calls, but have fallbacks that are less functional when CGO is disabled.

Agreed. I am actually working on an LLVM IR-like alternative that is portable.

This is not possible for C/C++ without either:

• Significantly rearchitecting the front end, or
• Effectively defining a new ABI that is distinct from the target platform’s ABI.

The second of these is possible with LLVM today. This is what pNaCl did, for example. If you want to target the platform ABI then the first is required because C code is not portable after the preprocessor has run. The article mentions __BIG_ENDIAN__ but that’s actually a pretty unusual corner case. It’s far more common to see things that conditionally compile based on pointer size - UEFI bytecode tried to abstract over this and attempts to make Clang and GCC target it have been made several times and failed and that was with a set of headers written to be portable. C has a notion of an integer constant expression that, for various reasons, must be evaluated in the front end. You can make this symbolic in your IR, but existing front ends don’t.

The same is true of C++ templates, where it’s easy to instantiate a template with T = long as the template parameter and then define other types based on sizeof(T) and things like if constexpr (sizeof(T) < sizeof(int)), at which point you need to preserve the entire AST. SFINAE introduces even more corner cases where you actually need to preserve the entire AST and redo template instantiation for each target (which may fail on some platforms).

For languages that are designed to hide ABI details, it’s easy (see: Java or CLR bytecode).

Agreed. I am actually working on an LLVM IR-like alternative that is portable.

If you’re looking for prior art, Tendra Distribution Format was an earlier attempt at a UNCOL for C.

With respect to libc - indeed, the article engaged quite a bit with libc! That’s why I was waiting for a clear conclusion.

E.g. cosmopolitan clearly picks “all the world’s a x86_64, but may be running different OSes”, musl clearly picks “all the world’s Linux, but may be running on different architectures”. You flirt with both “all the world’s Linux” and something like Go-on-OpenBSD’s static-except-libc. Which are both fine enough.

With respect to ASLR: I agree that this isn’t the main point of your article, and I don’t think I explained what I meant very well. Here’s some example code, where the data from main() is meant to represent hostile input; I mean to point out that merely segregating arrays and other data / data and code doesn’t fix e.g. lifetime issues, and that ASLR at least makes the resulting bug a bit harder to exploit (because the adversary has to guess the address of system()). A cleaned-up example can be found below, (actually-)Works-For-Me code here.

static void buggy(void *user_input) {
    uintptr_t on_stack_for_now;
    /* Bug here: on_stack_for_now doesn't live long enough! */
    scheduler_enqueue(write_what_where, user_input, &on_stack_for_now);
}

static void victim(const char *user_input) {
    void (*function_pointer)() = print_args;

    if (scheduler_run() != 0)
        abort();

    function_pointer(user_input);
}

int main(void) {
    buggy((void *)system);
    victim("/bin/sh");
}

On 16- and 32-bit x86, position-independent code was fairly expensive: there’s no PC-relative addressing mode and so the typical way of faking it is to do a PC-relative call (which does exist) to the next instruction and then pop the return address (which is now your PC) from the stack into a register and use that as the base for loads and stores. This burns a general-purpose register (of which you have 6 on 32-bit x86).

Windows avoided this entirely by statically relocating DLLs. I think on 16-bit Windows each DLL was assigned to a segment selector[1] on 286s, on real-mode or 32-bit Windows there was a constraint solver that looked at every .EXE on the system and the set of .DLLs that it linked and tried to find a base address for each DLL that didn’t conflict with other DLLs in any EXE that linked that DLL. If the solver couldn’t find a solution then you’d end up with some DLLs that would need to be resident twice with different relocations applied. I think in some versions of Windows it would just fail to load an EXE.

[1] 16-bit Windows is really 24-bit Windows. The exciting 8086 addressing mode is a 16-bit segment base right shifted by 8 and added to the address, giving a 24-bit address space. As I recall, .COM files were true 16-bit programs in a 64KiB segment, Windows provided an ABI where pointers were 16-bit segment-relative things but far pointers were stored as 32-bit integers that expanded to either a 24- or 32-bit address depending on whether you were on real-mode, standard-mode (286) or 386-enhanced mode (protected mode) Windows.

I’ve seen DLL hell on windows, never on linux. Package managers are awfully effective at avoiding it in my experience. If you go behind your distro package manager’s back, that’s on you.