1. 11
  1. 1

    Docker + debian:oldoldstable would be more straightforward, no?

    1. 2

      Old images is the standard in Python world, yes (usually with CentOS 7-based images). Except when you need more modern toolchains this gets to be a pain. Like, I’m doing cross-language LTO between Rust and C, so I need clang 13, and you can’t get that for really old distros…

      (But the linked technique doesn’t seem viable for Rust, so doesn’t actually help me).

      1. 1

        Yep fair enough, that makes sense.

    2. 1

      You can also achieve this with zig cc by specifying glibc version in the target zig cc -target x86_64-linux-gnu.2.28 also works for C++ and all supported target platforms.

      1. 1

        Sounds very useful if you have this problem, I just want to add a disclaimer that it might also be your too-new-kernel that’s the culprit. Had that problem once where we built on CentOS in Docker, but the hosts’ new kernel would leak through and the resulting binary would not run on the corresponding RHEL version. Might have been a Qt quirk, but a problem nevertheless.

        1. 1

          Or you could statically link against musl and run successfully on all those systems.

          1. 1

            For executables, yeah. In the Python world, extensions are shared libraries, so you need to build version matching host system’s libc.