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

No, I do not expect "format guarantee", format obviously changes once
in a while.

The exact problem I'm trying to protect against is inability of
alternative GLIBC to find shared libraries defined in system's
/etc/ld.so.conf.d without user intervention.

As one possible direction I see myself: are there any ways to turn our
alternative GLIBC into "a client" of system's GLIBC cache lookup
function? This way lookup function stays compatible with the format,
while alternative GLIBC gets access to the cache.

I really hope it's clear enough,
- - D.

On 11/10/2013 04:16 AM, Carlos O'Donell wrote:
> 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.
> 

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

iQEcBAEBAgAGBQJSfv7KAAoJENwm3+sbf/pMFJQH/1KxCZ3URGIdTIXT2W0UQxqZ
g980DJdi4nNnY3Gyel1ToKhHYGC0tfg7nYmrdsqQm9JQ9S94DAHp2EduAKFJJSY9
k97j/jay6TyKbr6gbUbUigulq3t2LHNgRyudeYDBf95M0cMQaA4A8FF4MTmde4g3
22UNyGnW1wZfwRitxPYEqHgT8CGCun+i7e5oKX91vFrnOi1Ba7dyQAr9/hXhk1XI
6p7XpJ+S1VkYBJV+WLMI1zpECeRQRoXyeijt1iZwplCcvTQM6KBS5OVTLJSOczLo
EsqaEfbb9ohmfKu7b/xKCpuEYmG/gXI6T2lqA1LtRtuNf7RpEuOUDi4QClmuAg8=
=eiRt
-----END PGP SIGNATURE-----