[devel] symbols into dependencies

[Alexey Tourbin]

On Mon, Nov 16, 2009 at 03:27:23AM +0300, Dmitry V. Levin wrote:
> On Mon, Nov 16, 2009 at 03:16:42AM +0300, Alexey Tourbin wrote:
> [...]
> > Да, "концептуальная" модель именно такая -- отслеживать символы
> > внутри сонейма.
> > 
> > Provides: (libfoo.so.1;foo_sym1,foo_sym2,foo_sym3,...)
> > Requires: (libfoo.so.1;foo_sym1,foo_sym2)
> 
> To match ELF semantics, we have to implement smth more complicated:
> 
> libfoo Provides(ELF): foo_sym1,foo_sym2,...
> libbar Provides(ELF): bar_sym1,bar_sym2,...
> client Requires(ELF): libfoo,libbar:foo_sym1,...,bar_sym1,...

So what is your model here?  Providing global symbols (without soname
context) is wrong: until the library is open and mmap'd, a symbol
means nothing.  It is just a name clash until then.  A collision.

So, to match ELF semantics, which is to allow symbols be moved across
the libraries, the model can be like this:

libfoo Provides(ELF): libfoo:foo_sym1,foo_sym2,...
libbar Provides(ELF): libbar:bar_sym1,bar_sym2,...
client Requires(ELF): libfoo,libbar:foo_sym1,...,bar_sym1,...

To resolve the Requires dependency is then to check that each symbol
foo_sym1,...,bar_sym1,... can be resolved into at least one _required_
library.  Or, in terms of sets, requires set should be a subset of the
union of provides sets, with the union calculated for the appropriate
sonames.

However, if we consider "tegent problem" again, we have to admit that
this whole blasted thing still does not provide close-enough ELF
semantics.  The problem is that "tgetent" was part of libncurses,
and then libtinfo emerged as a separate library.  And older binaries
are not linked with libtinfo, so it won't be possible to resolve
their undefined symbols against the _required_ libraries.

Look, the next step in improving the model is to implement recursive
symbols lookup (i.e. "passing on" of symbols down the river).  Now,
if you think about this a few more minutes, you have to recognize
that we are actually going to reimplement some parts of dynamic linker
within rpm dependency mechanism.

> And there is also symbol versioning that makes the picture even more
> complex.

So, to follow ELF semantics the way dynamic linker does, you simply
end up with reimplementing certain parts of the dynamic linker.  And not
only the linker, but special kind of dependencies are required to mimic
certain ELF data structures (e.g. set-union).  Which is indeed complicated.

I argue that we do not follow ELF semantics that much closely.
The whole thing should be boiled down to a much simpler model.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20091117/fc2fe784/attachment.bin>