There are 2 main axis to work on, which are abysmally less costly than any container based mitigation of the issue, since with the following we get "clean" set

There are 2 main axis to work on, which are abysmally less costly than any container based mitigation of the issue, since with the following we get "clean" sets of ELF binaries: - educate the devs on the matter. Those not using an engine already taking of that (this reduce by A LOT the amount of devs to teach). - work on a toolchain switch to link with version symbol names from a backward ABI, easily (not having to manually enumerate all version symbol names and use the binutils gas .symver directive, or install a 10 years old distro). And a toolchain which does default to -static-libgcc, -static-libstdc++ (when c++ is used) and -ftls-model=global-dynamic while we are at it (in order to spare those expensive static TLS slots). I do consider that gcc and clang(llvm) are lost for sane open source. Their absurd and grotesque size and complexity make them more toxic than anything else. Look at tinycc, cproc/qbe, simple-cc/qbe.