[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]


On Thu, 2002-08-22 at 00:11, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Aug 2002, Luca Barbieri wrote:
> > This is an another problem that would be easily and compatibly solved by
> > my ELF extension (until the library gets properly fixed upstream).
> Yes and no. Versioned symbols are here NOW and can be used NOW, and they fix
> the issue cleanly without drawbacks:  they are as painful as a
> do-it-only-once global soname increase (which is quite painful though).
I just got a Great Idea(tm).

This is the explanation from Ulrich Drepper:

In case only the object file with the reference does not use
versioning but the object with the definition does, then the reference
only matches the base definition.  The base definition is the one with
index numbers 1 and 2 (1 is the unspecified name, 2 is the name given
later to the baseline of symbols once the library started using symbol
versioning).  The static linker is guaranteed to use this indeces for
the base definition.  If there is no symbol definition with such an
version index and there is exactly one version for which this symbol
is defined, then this version is accepted (this was mostly implemented
for dlopen() calls as it will normally not happen when the static
linker is used). 

However this the problem:

Otherwise, if more then one version of the symbol is
available, none of the definitions is accepted and the search
continues with the next object.

If we modify the loader so that it instead accepts the first one, this
first one will be correct for the main program.

So if we modify the loader to do this and recompile the conflicting
libraries and the ones that use them we can address both the short-term
and the long-term issues while still allowing symbols to overridden.

With unmodified loaders and multiple versioned libraries in a program,
the binaries will fail until they are recompiled to use versioned
symbols. However this isn't worse than the current situation that causes
them to pseudorandomly fail.

Furthermore, since the binary would fail I don't think that anything
relies on the existing behavior.

Also, there is no chance of creating incompatible ELF formats since the
format isn't changed.

How about this? This seems better than using my patch.

Am I missing something?

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: