0

I want to use an SDK/library that uses glibc2.14. My machine has glibc2.12. I installed glibc2.14 in a separate location. Used the SDK in my executable by using compile option --rpath and it works good.

Now, I want to use the SDK (that uses glibc2.14) in a shared object binary (.so). I tried --rpath and --dynamic-linker options but the shared object is not loaded and it gives me an error during runtime - /lib64/libc.so.6: version ``GLIBC_2.14'' not found (required by /usr/local/lib/libsdk.so.1).

How do I make the shared object binary look at the glibc2.14?

pp99
  • 23
  • 1
  • 7
  • I would very strongly recommend against trying to use a custom-built glibc. Distros apply all sorts of patches and customizations and trying to build your own is probably going to result in a broken library that doesn't work with anything else on your system. – bk2204 Jun 21 '20 at 18:21
  • I have installed it at a different location and from what I understand only applications that explicitly point to that location will use the other glibc. – pp99 Jun 22 '20 at 11:52
  • That may be true, but the version you built may not be ABI compatible with other glibc binaries compiled by your distro (and is not, it sounds like), so using any other shared libraries on your system may or may not work. It's a much better idea to just upgrade your OS. – bk2204 Jun 22 '20 at 16:58

1 Answers1

0

Now, I want to use the SDK (that uses glibc2.14) in a shared object binary (.so).

You can't.

As this answer explains, ld-linux and libc.so must come from the same build of GLIBC.

Since the ld-linux is determined by the main executable (is hard-coded into it at static link time), it will not match your custom libc.so.6 no matter what you do to compile your .so.

In addition, specifying --dynamic-linker while building .so is pointless: it is the job of ld-linux to load the .so, so by definition ld-linux must already be loaded before any .so is loaded into the process.

P.S. If it were possible to make your .so use a different libc.so.6, the result would be an (almost) immediate crash, as libc.so.6 is not designed to work when multiple copies are loaded into the same process.

Update:

upgrade my OS which I don't think is possible because I am developing the software for a client and getting them to upgrade is not going to be easy. Second would be to ask the SDK supplier to recompile with glibc2.12.

GLIBC-2.14 was released 9 years ago. It's not unreasonable for your supplier to "only" support 2.14 (and later), and it is somewhat unreasonable for your client to run such an old OS.

I think you have 3rd possible option: have the client install newer GLIBC in parallel, and build their main executable with --rpath and --dynamic-linker flags (as you have done). Their binary will then have no problem loading your SDK.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Thanks. It looks like I have 2 options - upgrade my OS which I don't think is possible because I am developing the software for a client and getting them to upgrade is not going to be easy. Second would be to ask the SDK supplier to recompile with glibc2.12. – pp99 Jun 24 '20 at 19:54
  • Thanks. I got the main executable part and that is what I did with my app. However the other component is actually a PAM module. A shared object binary (.so file) that will be loaded by executable which are not under my control. For example: gnome-screensaver or gdm-password. Another option that I am looking at is creating my own executable and making the PAM module talk to my exe through some IPC method. – pp99 Jun 25 '20 at 01:58