4

Cast of characters

  • big-old-app is linked to an old version of glibc, say glibc-2.12. I cannot do anything to change this.
  • cute-new-addon.o is linked to a newer version, glibc-2.23. This glibc-2.23 is in a nonstandard path (because I don't have sudo powers).

The story

I want to use cute-new-addon.o inside big-old-app. I would normally write a script for big-old-app to execute, which then calls cute-new-addon.o to perform its tricks. From the command line, it would look like:

$ big-old-app script.txt

However, when I do that, big-old-app would complain that cute-new-addon.o cannot find glibc-2.23. That's understandable, because I have not specified any standard paths. What if I do:

$ LD_LIBRARY_PATH=/path/to/mylibs:$LD_LIBRARY_PATH big-old-app script.txt

It segfaults! :(

I think this is because big-old-app references a newer mylibc.so.6. When doing so, the implementations are no longer what big-old-app is used to, so it segfaults.

The question

Regarding script.txt, I don't think I have the ability to specify the newer mylibc.so.6 before invoking cute-new-addon.o. big-old-app and cute-new-addon.o are tightly intertwined that I have no way of knowing when either of them need their corresponding glibc.

And yes, cute-new-addon.o rpath is pointed to /path/to/mylibs and I can confirm via ldd that all the libraries it needs, it looks for in /path/to/mylibs.

Can I use LD_PRELOAD to load two different versions of glibc? And let big-old-app and cute-new-addon.o look for what they need as they please?

Kit
  • 30,365
  • 39
  • 105
  • 149

1 Answers1

4

LD_PRELOAD cannot be used because the glibc dynamic linker (sometimes called ld.so or the program interpreter; the location on disk is platform-specific) is only compatible with libc.so.6 (and the rest of the libraries) from the same glibc build.

You can use an explicit loader invocation of the other glibc, along with library path settings that cause the loader to load the glibc objects from a separate directory, and not the system directories. The glibc wiki has an example how to do this.

Florian Weimer
  • 32,022
  • 3
  • 48
  • 92
  • **Building glibc without installing** : "... The prefix `/usr` is considered the correct prefix for a system glibc." I have a feeling this is necessary to "load the glibc objects from a separate directory". Am I on the right track? – Kit Mar 15 '19 at 16:30
  • No, you can build with `--prefix=/usr` and still keep the copy in a separate location, perhaps by installing it using `make install DESTDIR=/path/to/alternative/tree`. – Florian Weimer Mar 15 '19 at 16:39