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

[Dmitry Mikushin <dmitry at kernelgen dot org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

- - D.

On 11/09/2013 09:14 PM, Carlos O'Donell wrote:
> 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.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJSfp08AAoJENwm3+sbf/pMrJEH/2nCMva1RUzCRZy7CKpS/WJj
mJmPA+XJf7QwtCB8hg8rm7tR+KOHkwgaAnkj8rWrvDYQLPQEzO7/YmgTILfYi8wF
Kp8jUDlb066rPu9XaaFkGpgNBg1GY0ZGVUtcHZKtKBhEZYHkWKJ606sBwbzyo/oV
f/BancNhQUjfgYcnAWmN+sHR1wGoqB+6HIituRNPaey5nYdHBBizvdy68leuBb6D
GxdHfz/U7D7w7I8l+1PYIfGtO90sjN//nTAooptJS3w+zObavA9weaht+2ZqN746
+9xP7YVMADgbHO3LWsP7JsMVU6fjPb9sVVM7gdAPDw8+7mPT9o1KH2DE/FN5ytk=
=MPcr
-----END PGP SIGNATURE-----