Re:Docker is a dangerous gamble
by paulfurtado on Monday May 14, 2018 @08:30AM
(#17064844)
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
[ Parent
| on HN ]
Re:Docker is a dangerous gamble
by otabdeveloper1 on Monday May 14, 2018 @10:19AM
(#17065725)
> 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_binaryApparently nuitka's author considers it a bad idea and removed this feature: http://bugs.nuitka.net/issue136
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.
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.
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.
Re:Docker is a dangerous gamble
by moosingin3space on Monday May 14, 2018 @11:16AM
(#17066213)
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.