-1

In the enterprise class of Linux OS's,

  • SLES 11.4 uses glibc 2.11
  • SLES 12.3 I think uses glibc 2.19
  • RHEL 6.10 uses glibc 2.12
  • RHEL 7.6 uses glibc 2.17
  • source for glibc is currently at 2.29
  • I was provided executable code from a Linux system having glibc 2.14 a while back, cannot run it on SLES 11.

From all reading it seems that glibc cannot be manually updated on a system; the only way to version up with it is to jump to a complete newer version of a Linux operating system. Is this true?

While there has always been backward-compatibility, there is not forward compatibility which brings me to...

I go to RHEL 7.6 with glibc 2.17 which is currently the latest, if someone currently uses SLES 12 with glibc 2.19 and gives me executable code what do I do? Same question if they use some Linux in not too distant future with some later version of glibc? Is there a way around this problem, whether it is on the receiving side having an older glibc or on the providing side having newer glibc? What I also find a huge part of the problem is the statement by the glibc website: GNU C Library releases every 6 months.

0

There are versioned symbols within the library. If the new code hits one of the versioned symbols, and that version is newer than anything in your libc, you’ll not be able to run

Can they build static?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.