0

I am getting this error while I am running the code in GLIBC version 2.12, which was compiled in 2.19.What is the standard solution to this problem, so that the code can run in all versions.Upgrading the target machine to 2.19 is not an option because this software is supposed to run in at least 5000 machines.Dow grading the development machine to 2.12 is also not a proper solution. Because 2.19 is just one example. The 5000 target machines can have any version.What is the standard solution for this ? Anyway of static compilation ? I mean bundling the entire GLIBC with the code .

BusyTraveller
  • 183
  • 3
  • 14

3 Answers3

4

The easiest solution is to simply create a "build server" which you use for your production builds, and keep this server on the oldest version of everything you need to support, including glibc.

This can be done using a VM inside your development server if you don't want to use a physical machine.

John Zwinck
  • 239,568
  • 38
  • 324
  • 436
  • 1
    Or instead of a VM, just use a plain chroot or some container manager. – o11c Apr 26 '16 at 06:01
  • I am trying to do the same only.I don't know how much complicated will it be to downgrade to the oldest possible version because of dependencies.That why , I had thought about static compilation. – BusyTraveller Apr 26 '16 at 06:16
  • Don't downgrade, just install the same OS on the build server as you have in production on your oldest machine. Then glibc and other things will automatically be an appropriate version in many cases. – John Zwinck Apr 26 '16 at 06:18
  • @JohnZwinck what I mean is that latest OS may not support older glibc. – BusyTraveller Apr 26 '16 at 06:46
  • @BusyTraveller: If your concern is that your newest servers will fail to execute programs built against older glibc, this won't be a problem. – John Zwinck Apr 26 '16 at 07:51
0

Bbinaries compiled against glibc should be forward-compatible; the binaries you compiled against glibc 2.19 were using an API version that appeared in 2.14. If instead you compile against 2.12 it should work at runtime with Glibc 2.19 as well.


In Python-land, they're now offering prebuilt Linux C extensions that are built on Centos 5.11 Docker images; The PEP 0513 explains details. They seems to work pretty well there. Centos 5.11 seems to have glibc 2.5; Centos 6 has glibc 2.12. I am using these prebuilt .sos on Ubuntu 14.04 and 15.10 myself without any problems.

0

There is also a very hackish solution, by placing the required libc.so (2.19) file in a specific directory (just copy it over), creating a runner script, where you set the LD_LIBRARY_PATH to have the specific directory and then you run the executable. The system should pick up the libc.so from the specific directory before the one provided by the system, so it should work.

Ferenc Deak
  • 34,348
  • 17
  • 99
  • 167