The asker is wrapping FFmpeg (and its static dependencies) into a single shared library exposing a C++ API for Deno's FFI. They want the FFmpeg internals statically linked into the .so, but some of those object files weren't compiled with -fPIC. They're asking when this can be made to "just work."

Why it's interesting: the question sits at the seam between three pieces of ELF/PE machinery that most developers happily ignore — position-independent code, text relocations, and the loader's address-space layout. The naïve answer ("you must use -fPIC") is wrong; the precise answer ("it depends on the architecture, relocation types, and whether the loader permits DT_TEXTREL") is what makes this worth writing up.

Sketch of an answer:

• x86-64 with the small/medium code model: most code references are RIP-relative, so non-PIC object files often link cleanly into an .so — the relocations that would need fixing at load time mostly don't exist. This is why people get away with it on Linux/amd64.
• i386: non-PIC code uses absolute addressing for globals and call targets. The linker emits R_386_32 or R_386_PC32 relocations against text. ld will accept these by setting the DT_TEXTREL flag, forcing the loader to make text pages writable at load time, apply fixups, then re-protect. It works, but it (a) defeats page sharing across processes, (b) is rejected outright by hardened loaders (SELinux allow_execmod, some musl builds, Android, iOS), and (c) breaks under W^X.
• AArch64/ARM: similar story to x86-64 — most addressing is PC-relative via adrp/adr, so non-PIC is usually fine within ±4 GiB.
• Windows DLLs: the entire model is different — base relocations are expected, and ASLR rebases happen at load. There's no "PIC vs non-PIC" axis in the same sense.

Practical guidance for the asker: if FFmpeg's build emits non-PIC .a files on x86-64 Linux, the resulting .so will probably load and run. Verify with readelf -d libfoo.so | grep TEXTREL — if that flag is absent, you're fine; if present, you've silently signed up for writable text pages and incompatibility with anything that disallows them (notably noexec mounts and some sandboxes Deno may eventually run inside).

Gotchas: LTO can hide the problem until link time. Cross-compiled distributions (Alpine/musl, NixOS hardened) sometimes refuse DT_TEXTREL at runtime even when GNU ld emitted it. And if Deno ever moves its FFI workers into a seccomp-restricted sandbox, an mprotect(PROT_WRITE) on text from the loader will be the failure mode.