This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Mixing multiple versions of the same symbol at runtime.


Developers,

A question has come up about upstream support for mixing multiple
ABIs in one dynamically linked application at runtime.

The question is this:
~~~
If you have an old version API, and new version API, and they both
operate on a structure named FOO, does the community provide any
guarantees that you can operate on FOO with both APIs?
~~~

It is my experience and opinion that we do not provide any compatibility
guarantees about this case, and that by default users should assume it
will not work. On a case-by-base basis we might allow it for some APIs,
but that needs review.

I would propose an FAQ item that clarifies this:
~~~
Q:

Can I have an application and its libraries that reference both 
old version symbols and new version symbols of the same symbols
e.g. sem_init@GLIBC_2.0 and sem_init@@GLIBC_2.1?

A:

In general it is strongly advised that an application and all
of the libraries it uses should reference only a given symbol with
the same version across all objects. If, for example, two given
libraries reference two different versions of the same function
it may lead to a failure if those functions operate on
opaque data types whose internal layouts differ between versions
and which are passed between the two libraries and operated upon.

A concrete example of this is a change in the layout of the
semaphore in glibc 2.21 which did not break ABI or API, but whose
internal layout was different from the semaphore layout used by
the old versions of the semaphore functions. Previously
the old semaphore layout was still usable with the new semaphore
functions, but that is no longer the case and may not be in the
future for other APIs.

Where possible all care will be taken to design newer algorithms
that could work in degraded modes with the old types and old
functions, but this is not always possible nor easy.
~~~

The consequence of this is that if you take a very old application and
bring it to a new distribution that application may no longer work if,
using the example above, structure foo was initialized in old code and
passed to a new library that uses the new version definition of structure
foo.

You may think this is a problem for old applications, but the reality is
that it isn't. The Red Hat glibc team recently had a bug reported about
semaphore not working correctly. This turned out to be one library which
was compiled without linking against libpthread which resulted in base
versions of the semaphore functions being used. This is clearly now two
objects in an application using two distinct implementations and mixing
them is not allowed.

In C++ the story is quite different. With name mangling and the new ABI
tag attribute you can get a mixing of ABIs and it works (thanks to the
mangling) as long as you don't mix the objects in some way.

Thank you for your consideration of this topic.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]