3 ms·

Note that typically the problem isn't that a server lacks libc, but that it has too old of a version. For example, my company runs on CentOS 6, which comes with

Note that typically the problem isn't that a server lacks libc, but that it has too old of a version. For example, my company runs on CentOS 6, which comes with glibc 2.12. Software built against newer glibc versions will not link against it at run time, and this is frequently a problem. The easiest solution to this is to build on the oldest linux distro you plan to target

otabdeveloper1 8y ago
> The easiest solution to this is to build on the oldest linux distro you plan to target No way. Just package your libraries with your executable: /my_path/ld-linux-x86-64.so.2 --library-path /my_path /my_path/my_binary
- sametmax 8y ago
  Apparently nuitka's author considers it a bad idea and removed this feature: http://bugs.nuitka.net/issue136 http://bugs.nuitka.net/issue136
viraptor 8y ago
And the funny part is that currently the easiest way to build against an older/different version of the OS without being forced into the "prod env = dev env" situation is... to use docker or any other container solution.
- vonseel 8y ago
  I would think that knowing the libc limitation were a problem, running builds on a server with this older libc version would be a possibility. I’ve done what you mention with Docker and alpine builds (for alpine Python wheels, for example) but honestly it’s a lot more painful to ssh into running containers when figuring out the build script than it is to just throw up a clean VM.
  - viraptor 8y ago
    Sure, it's possible. But I don't think it's easier. You get into all kinds of path/rpath fun and the worst thing is that things may work but you end up using the wrong environment by accident. Chroot could help, but docker has it all nicely wrapped up with the tooling.
moosingin3space 8y ago
In some cases, it's even possible to link statically against musl libc. Granted, this is easiest to do with an Alpine Linux VM or container.

otabdeveloper1 8y ago

> The easiest solution to this is to build on the oldest linux distro you plan to target No way. Just package your libraries with your executable: /my_path/ld-linux-x86-64.so.2 --library-path /my_path /my_path/my_binary

sametmax 8y ago
Apparently nuitka's author considers it a bad idea and removed this feature: http://bugs.nuitka.net/issue136 http://bugs.nuitka.net/issue136

viraptor 8y ago

And the funny part is that currently the easiest way to build against an older/different version of the OS without being forced into the "prod env = dev env" situation is... to use docker or any other container solution.

vonseel 8y ago
I would think that knowing the libc limitation were a problem, running builds on a server with this older libc version would be a possibility. I’ve done what you mention with Docker and alpine builds (for alpine Python wheels, for example) but honestly it’s a lot more painful to ssh into running containers when figuring out the build script than it is to just throw up a clean VM.
- viraptor 8y ago
  Sure, it's possible. But I don't think it's easier. You get into all kinds of path/rpath fun and the worst thing is that things may work but you end up using the wrong environment by accident. Chroot could help, but docker has it all nicely wrapped up with the tooling.

moosingin3space 8y ago

In some cases, it's even possible to link statically against musl libc. Granted, this is easiest to do with an Alpine Linux VM or container.