Sharing between two glibc versions on a single system

Dmitry Mikushin
Sun Nov 10 03:34:00 GMT 2013

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/ 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/
>> 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, which
>> is provided via system's /etc/ paths. Problem: we
>> need to find upon running app, just like if app is
>> executed with system's native GLIBC/interpreter. You see?
>> Converting the contents of /etc/ to RPATHs is also
>> an option, but in this case we will need to change them each time
>> the contents of /etc/ 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.

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined -


More information about the Libc-help mailing list