Kit
Kit

Reputation: 31523

Can LD_PRELOAD be used to load different versions of glibc?

Cast of characters

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?

Upvotes: 4

Views: 5866

Answers (1)

Florian Weimer
Florian Weimer

Reputation: 33717

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.

Upvotes: 4

Related Questions