1

I need to run relatively new package on not-so-new RHEL 5.6.

I have 3rd party library (lib3rdparty.so) which is compiled against glibc 2.6 while RHEL 5.6 have only 2.5 installed. But in the library there is only a couple of references to sched_getcpu@@GLIBC_2.6. I've checked it like this

readelf -s lib3rdparty.so | egrep "@GLIBC_2.[6-9]"

to find references to something newer than GLIBC_2.5 which is installed. The output is

0 FUNC    GLOBAL DEFAULT  UND sched_getcpu@GLIBC_2.6 (62)
0 FUNC    GLOBAL DEFAULT  UND sched_getcpu@@GLIBC_2.6

So, I have only one function from GLIBC_2.6. Now I want to make library think, that I have this function. For that purpose I forged small library (libcheat.so) like it mentioned here. Now I have libcheat.so file which, if run through readelf, will show this string:

10 FUNC    GLOBAL DEFAULT   11 sched_getcpu@@GLIBC_2.6

With this library I managed to succesfully build executable which is dynamically linked with lib3rdparty.so. Without this library I can't build anything, because ld can't find reference to sched_getcpu.

But the problem is with running this file: when I try to run it I have a following error:

 ./hello_world: version `GLIBC_2.6' not found (required by ./lib3rdparty.so)

So, I believe there is one last step to make it work, but I don't know what to do. I've tried to use /etc/ld.conf.preload and exporting LD_LIBRARY_PATH so it would point to my library to load before others. But it won't run. Tried to run it through strace but have no meaningful output.

Any ideas?

Community
  • 1
  • 1
iw.kuchin
  • 738
  • 6
  • 14

2 Answers2

0

I'm not sure if the workaround you picked up is the best way to go. Why not supplying a newer glibc for the application? You can try to pass it over using the LD_PRELOAD environment variable. For best binary compatibility, you can obtain a glibc binary from a newer distribution version, or rebuild a newer glibc version for RHEL 5.6.

Also, try to fiddle with the LD_DEBUG environment variable to see what the dynamic linker does.

Dan Aloni
  • 3,968
  • 22
  • 30
  • I think that I use latest glibc for RHEL5, so newer ones only available for RHEL6. I've tried to find some info for upgrading glibc but nearly all of the advices are like "upgrade to newer RHEL". I'll try to pass newer version just for my application. – iw.kuchin Nov 03 '11 at 13:17
  • Tried to pass libc.so from Fedora 14. Ended with `ELF file OS ABI invalid`. – iw.kuchin Nov 03 '11 at 13:38
  • Best to use binaries from the distro on which lib3rdparty.so was originally built. If you can obtain a rootfs of it, or a VM image, you should be able to to build and test stuff on it. – Dan Aloni Nov 03 '11 at 13:46
  • I don't know where it was built as it is distributed as binaries. And also I need my program to work on my system with old glibc. This is the main problem. I have one system where compiled program works perfectly (Fedora) but this is of no help. – iw.kuchin Nov 03 '11 at 13:55
0

Ok, I believe I should mention "last step" which in my case included patching of binary 3rd party libraries.

  1. Using objdump I found an address where lib3rdparty.so searches for GLIBC_2.6
  2. Using hexedit I replaced this address with the one where GLIBC_2.5 was exported (you should search for bytes in reversed order). Also I replaced symbol with 2.5.
  3. Using objdump I've checked that all references now using GLIBC_2.5
  4. I needed to rebuild libcheat.so as sched_getcpu now was referencing GLIBC_2.5, so I used sched_getcpu@@GLIBC_2.5 as assembler inline

After that I put libcheat.so near lib3rdparty.so, set LD_LIBRARY_PATH to . and my binary started to work. I'm not sure that this stuff will work totally correct, but if you stumbled into this kind of problem, this question and answer might be of some help.

iw.kuchin
  • 738
  • 6
  • 14