From: Sviatoslav Sviridov <svd@altlinux.ru> To: ALT Devel discussion list <devel@lists.altlinux.org> Subject: [devel] [Fwd: libsvn SONAMEs and APR] Date: Mon, 13 Mar 2006 16:06:24 +0200 Message-ID: <44157C60.80900@altlinux.ru> (raw) [-- Attachment #1.1: Type: text/plain, Size: 4530 bytes --] Приветствую, Вот интересная, как мне кажется, дискуссия на тему что, как и с чем линковать: 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 [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 250 bytes --]
next reply other threads:[~2006-03-13 14:06 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-03-13 14:06 Sviatoslav Sviridov [this message] 2006-03-13 14:42 ` Dmitry V. Levin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=44157C60.80900@altlinux.ru \ --to=svd@altlinux.ru \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git