Re: [devel] symbols into dependencies

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

On Mon, Nov 16, 2009 at 03:50:29PM +0300, Sergey Vlasov wrote:
> On Mon, Nov 16, 2009 at 03:01:03PM +0300, Damir Shayhutdinov wrote:
> > > On the other hand, we can simply assume that symbols should not be moved
> > > across the libraries.  The worst thing that can happen then (if a symbol
> > > does move) is that we need to rebuild a bunch of packages, only to
> > > relink their binaries and update dependencies.
> 
> Do we care about binary-only apps which we cannot rebuild - would
> their repackaging in the RPM form become impossible?

The idea is that, at build time, we use something like ldd(1) to
find out how the dynamic linker resolves undefined symbols.  We then
get "the best possible" asoociation between symbols and libraries.

Prebuilt binaries are then different in a way that they can be
"underlinked": certain symbols can be transitively resolved into
libraries which are not specified as DT_NEEDED.

So it is quite possible to handle prebuilt binaries.  The only question
is whether extra dependencies (based on transitively resolved symbols)
should be added to the package.

> > Have you thought about C++ libraries and their mangling? And the fact
> > that many of C++ exported symbols in such libraries are not, in fact,
> > the part of the API, they are only exported because C++ cannot control
> > their visibility on the ELF symbol level. I'm talking about private
> > methods of classes.
> 
> Private methods can still be part of the public ABI - e.g., if a
> public inline calls a private non-inline method, the resulting
> executable will have a reference to the "private" symbol.
> 
> C++ libraries have yet another property which is unusual for C
> libraries - they typically use weak symbols.

Anyway, the idea is to find out "what the linker would do".

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]