Clarify language in doc/deferred-linking.md

trunk
Emery Hemingway 3 months ago
parent d75e71973e
commit 229cef980e

@ -4,7 +4,7 @@ Sigil generally avoids dynamically linking its ELF binaries. To explain why we m
> dynamic - Characterized by or tending to produce continuous change or advance.
That is the definition from 1973 edition of the "The American Heritage Dictionary" (as good as any for clarifying the language of UNIX). Dynamic linking is so called because the runtime behavior of a program may continuously change as a system's "dynamic libraries" are upgraded. To borrow a [metaphor](https://www.tweag.io/blog/2022-07-14-taming-unix-with-nix/), a dynamic link is like an pointer to some behavior. These pointers might be weakly typed or not typed at all, and they might dangle. Obviously this sort of pointer is useful or it wouldn't be tolerated. For example, such a pointer could point to some hardware-specific behavior that isn't static at build time, or it could point to behavior with proprietary internals. In the case of Genode it is kernel specific behaviors that are hidden beneath such pointers, which this is why it can only be said that Sigil generally avoids this sort of linking.
That is the definition from 1973 edition of the "The American Heritage Dictionary" (as good as any for clarifying the language of UNIX). Dynamic linking is so called because the runtime behavior of a program may continuously change as a system's "dynamic libraries" are upgraded. To borrow a [metaphor](https://www.tweag.io/blog/2022-07-14-taming-unix-with-nix/), a dynamic link is like an pointer to some behavior. These pointers might be weakly typed or not typed at all, and they might dangle. Obviously this sort of pointer is useful or it wouldn't be tolerated. For example, such a pointer could point to some hardware-specific behavior that isn't static at build time, or it could point to behavior with proprietary internals. In the case of Genode it is kernel specific behaviors that are hidden beneath such pointers, which this is why Sigil avoids this sort of linking but does not exclude it.
Sigil binaries aren't required to be static-linked at runtime, but they are usually "shared-linked" using absolute references, and the same can be said of Nix packages for any platform. This is because we discipline our builds and tests results to be deterministic and we likewise expect the behaviors of a program at runtime to selected deterministically. For Nix this is enforced in two ways. First there is no global library namespace at /lib, ELF binaries list a "runtime path" for finding libraries with some explicit /nix/store/… directories that must be determined at compile time. Second, relative names like `libz.so` can be replaced by absolute file-system paths, which is preferred because it avoids expensive directory searches that can certainly be resolved at compile-time. The Nix method can be described as "deferred-linking" because the link is finalized at runtime rather than compile time, and it is without continuous change in behavior at runtime.

Loading…
Cancel
Save