Re: Sharing ld.so.cache between two glibc versions on a single system

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Sat, Nov 9, 2013 at 9:35 AM, Dmitry Mikushin <dmitry@kernelgen.org> wrote:
> Our application comes with its own glibc version. We don't want to
> bother users with manual ldconfig updating. Instead we are looking for
> how to re-use the system-default glibc's configs as much as possible.
> Unfortunately, ld cache may be non-portable across glibc versions. What
> could be done about that? I think one can try to override application's
> glibc call to _dl_load_cache_lookup with call to system's glibc, and it
> will lookup in its compatible ld cache. But I'm not sure if this path
> covers all possibilities. Do you see any better solution?

What problem are you trying to solve? Tell us about your problem.

How does your application make use of it's own runtime? e.g. -Wl,-rpath?

Note I say "runtime" because glibc, and ld.so are joined and must be
used together. It's risky to run an old ld.so with a new glibc and it may
not work and may break after an udpate. The entire runtime must be
kept in sync including libpthread and all the other libraries built from
glibc.

If you ship your own runtime you can do whatever you want with that glibc
including having it look somewhere else for an alternate cache, and during
installation or startup, you can add code to parse the original ld.so cache or
configuration file and put as much of that data into your aternate cache
as possible. Then let the normal lookup routine do their work.

In the end you're always going to loose since the cache may change
entirely with a new glibc. In that scenario your code just needs to be
as robust as possible and ignore data it doesn't understand.

Cheers,
Carlos.