[devel] symbols into dependencies

[Alexey Tourbin]

On Mon, Nov 16, 2009 at 03:05:46AM +0300, Dmitry V. Levin wrote:
> On Mon, Nov 16, 2009 at 12:14:43AM +0300, Alexey Tourbin wrote:
> [...]
> > Есть идея формировать зависимости на сонеймы с учетом символов.
> > Это может выглядеть так:
> > 
> > 	%package -n libfoo
> > 	Provides(auto): libfoo.so.1 = set:0123abcd...(очень длинная строка)
> > 
> > 	%package -n foo
> > 	Requires(auto): libfoo.so.1 >= set:abcd0123...(умеренно длинная строка)
> > 
> > То есть реализовать зависимости специального вида, которые представляют
> > собой "множество строк" (символов).  Вместо обычного сравнения версий
> > для таких зависимостей будет выполняться проверка, что requires set
> > является подмножеством provides set.
> 
> Please do not over-optimize here.
> For example, have a look at /bin/ls ELF executable:
> 
> $ readelf -d /bin/ls |awk '/NEEDED/{print $5}'
> [librt.so.1]
> [libcap.so.2]
> [libtinfo.so.5]
> [libacl.so.1]
> [libc.so.6]
> $ readelf -s /bin/ls |grep tgetent
>     36: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND tgetent
> 
> Where does the "tgetent" symbol come from?  Dynamic linker will be
> sufficed if at least one of abovementioned libraries will provide it.

According to System V Application Binary Interface (gabi41.pdf),
tgetent comes from libcurses (p.125).  This gives strong evidence
for associating symbols with libraries they come from.

> Here is a more artificial example written to demonstrate ld.so behaviour:
> $ echo 'int a(){return 1;}' >liba.c &&
> gcc -fpic -shared liba.c -o liba.so &&
> echo 'int b(){return 2;}' >libb.c &&
> gcc -fpic -shared libb.c -o libb.so &&
> echo 'int main(){return a()+b();}' >exe.c &&
> gcc exe.c -L. -la -lb -o exe &&
> LD_LIBRARY_PATH=. ./exe; echo $?;
> echo 'int b(){return 10;}' >liba.c &&
> gcc -fpic -shared liba.c -o liba.so &&
> echo 'int a(){return 20;}' >libb.c &&
> gcc -fpic -shared libb.c -o libb.so &&
> LD_LIBRARY_PATH=. ./exe; echo $?
> 3
> 30
> 
> That is, a needed ELF symbol may jump from one library to another.
> And it had happened once with the "tgetent" symbol.

When a symbol is moved to another library, some programs might need
relinking, while some might still work.

Let's see what happens if a symbol is moved from libA to libB.  The
programs that use the symbol and linked only to libA go broke, right?
But programs which are linked to both libA and libB are fine.
Do you mean it is possible to handle these cases differently?

To sum up, when a function is moved to another library, the ABI is
changed, and the programs should be relinked.  It is only by chance
that some programs might still work.

> P.S. This issue is not an ALT Linux specific, so if we succeed to
> work out a solution, it could be used by others.

They don't care.  Otherwise they'd come with something more smart. :)
-------------- 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/20091116/7f3537f8/attachment.bin>