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

["Carlos O'Donell" <carlos at redhat dot com>]

On 11/09/2013 03:38 PM, Dmitry Mikushin wrote:
> Hi Carlos,
> 
> I'm shipping a compiler, which comes with its own version of GLIBC.
> I'm aware of RPATH, all those things we are already using. The problem
> is that having customer's apps linked against our GLIBC, interpreter,
> compiler, etc., we still need to runtime-link against what system's
> GLIBC has in its /etc/ld.so.conf.d. Example:
> 
> Our product is foo-gcc, which comes with glibc-2.17
> customer compiles his apps with foo-gcc, and they get properly linked
> against foo-gcc runtime, glibc-2.17's C library and glibc-2.17's
> interpreter. But app may still depend on some libfoo.so, which is
> provided via system's /etc/ld.so.conf.d paths. Problem: we need to
> find libfoo.so upon running app, just like if app is executed with
> system's native GLIBC/interpreter. You see?
> 
> Converting the contents of /etc/ld.so.conf.d to RPATHs is also an
> option, but in this case we will need to change them each time the
> contents of /etc/ld.so.conf change.

Thank you for the excellent description of your use case.

You still haven't described the problem though.

Is the problem that we don't, as a community, guarantee the format
of the cache? If the format changes in 2.20 or 2.21 then your older
2.17 would fail to read the cache correctly and thus fail to run the
user application?

What is the exact problem you're trying to protect against?

Cheers,
Carlos.