Sharing between two glibc versions on a single system

Carlos O'Donell
Sun Nov 10 03:17:00 GMT 2013

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?


More information about the Libc-help mailing list