Приветствую,

Вот интересная, как мне кажется, дискуссия на тему что, как и с чем
линковать:

http://svn.haxx.se/dev/archive-2006-03/0501.shtml
http://svn.haxx.se/dev/archive-2006-03/0516.shtml
и далее по треду

Хотелось бы услышать мнения как это все соотносится с alt
linking/packaging policy? По поводу линковки, насколько я понимаю, мы
здесь близки к Debian?

Частный случай из этого топика (буду использовать реальные имена для
удобства):
Имеется libapr-0.so.0 (из libapr-0.9.7), с ней слинкована
libsvn_client-1.so.0, а также некоторая программа, слинкованная с
libsvn_client. Эта некоторая программа не использует напрямую символы из
libapr, и поэтому с libapr не линкуется. Однако везде используется тип
apr_off_t. Так вот если libapr обновляется до 1.x.x и libsvn
пересобирается с ним, то вроде бы как получаем все зависимости
удовлетворенные... некторая программа не была слинкована с libapr,
поэтому не пересобиралась, но ABI у libsvn все же поменялся за счет
изменений в libapr... Дело в том, что в libapr-1.x размер apr_off_t стал
равен 64 для 32-битных платформ (был равен 32).

Peter Samuelson в данном случае предлагает начать использовать SONAME
для libsvn, зависящий также и от версии apr. А как такую проблему
предложили бы решить в ALT?

PS а в принципе -- насколько хорошим/плохим является дизайн библиотеки,
использующей такое скозное использование типов, как в случае с
apr_off_t? В случае одной библиотеки можно еще как-то внести такую
зависимость в SONAME, а если библиотек будет 5, 10, ...? С другой
стороны -- если каждая библиотека будет использовать свои
(пере)определения типов, то будет ли это хорошо?

-------- Original Message --------
Subject: 	libsvn SONAMEs and APR
Date: 	Fri, 10 Mar 2006 17:15:53 -0600
From: 	Peter Samuelson <peter@p12n.org>
To: 	dev@subversion.tigris.org


Debian subversion builds will soon be moving to apr 1.2, in lockstep
with Debian apache2.  (Because of mod_dav_svn, we have no choice.)  We
know this will occasion an ABI change to libsvn, so this requires
changing the embedded SONAMEs of the libraries.  (See footnote for a
quick introduction to SONAMEs.)

I note that subversion currently has no particular notion of library
versions - which I suppose is OK since you're committed to never
changing the ABI incompatibly - but it's probably better to be
explicit.  Anyway, libtool generates its own default SONAMEs:

  $ objdump -p /usr/lib/libsvn_client-1.so.0 | grep SONAME
    SONAME      libsvn_client-1.so.0

I'll need to adjust this in some way, to denote the ABI change caused
by the new apr.  I'll do it myself on Debian if I have to, but I'd
prefer to avoid this, as it'll create a gratuitous incompatibility
between Linux distributions.  E.g., if Fedora also decides to build
subversion 1.3 with apr 1.2, our binaries won't work on Fedora, or vice
versa, unless they happen to make the *same* change to the SONAME
strings that I do.

Would you consider accepting a patch to make SONAME handling explicit
in the Makefile, and also make it sensitive to apr version?  Would you
consider this for 1.3.1 or 1.3.2?  I'll try to prepare and test a patch
in the next day or two.

Thanks,
Peter

[*] Quick introduction to the SONAME feature: it's a free-form string
embedded in an ELF-format library.  A binary linked to the library
copies the SONAME field so that it can look for that exact string, as a
filename, at runtime.  (The filename will be a symlink to the library,
placed in /usr/lib or /usr/local/lib or similar.)  If an ABI changes
incompatibly, the SONAME of the library must change as well, so that if
you run an old binary, it won't pick up the new, incompatible library -
either it finds a copy of the old, compatible library, or it gets a
runtime error and quits.  The SONAME typically takes the form
"libfoo.so.N", but the only thing that really matters is that it be
unique for a given library ABI.  The term "SOVERSION" seems to mean the
part of the SONAME that changes between ABIs, but it's not a terribly
well defined term so it's best avoided.

SONAMEs aren't intended to solve the problem of a new binary picking up
an old library and trying to use new features which are missing.
That's a *compatible* ABI change to the library.  The *incompatible*
change I'm talking about in this message is the change of apr_off_t
from 32 bits to 64 bits on 32-bit platforms, which affects libsvn's ABI
as well.

-- 
Best Regards,
Sviatoslav Sviridov