From: Damir Shayhutdinov <damir@altlinux.org> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] A: libqwt API breakage Date: Mon, 28 Sep 2009 15:26:12 +0400 Message-ID: <679044850909280426h21ff152qed61eaa9f2b31bae@mail.gmail.com> (raw) In-Reply-To: <4AC098A4.7050008@mmedia2.kemsu.ru> > Т.е. смена API при смене soname - это исключение, а не правило? Мне > почему-то всегда казалось, что смена soname связана как раз с API. В > противном случае я пока не улавливаю смысла вообще менять soname :( > PS. Понятно, что конкретно данный случай - из другой оперы, увидев смену > API, я сменил soname принудительно, но для более общего случая желательно > всё же устранить все неясности. Не надо было так спешить, надо было все взвесить. Для начала надо бы уяснить, что такое API, и что такое ABI. API - Application Programming Interface - это, образно говоря, набор объявлений типов, констант, прототипов функций библиотеки и вспомогательных макросов - то есть то, что лежит в .h файлах библиотеки, и используется при сборке исходного кода. ABI - Application Binary Interface - это, образно говоря, набор функций, которые экспортируются из библиотеки, вместе с их параметрами, соглашениями вызова и т.д. Это используется при запуске программы. Когда меняется ABI - это означает, что приложения, собранные со старой бинарной библиотекой, не будут работать (или будут работать некорректно) с новой. Изменения ABI могут привести к несовместимости бинарных сборок (в этом случае необходимо менять soname), или могут не привести - тогда можно обойтись версионированием символов. Изменение API происходят на уровне исходного кода, и, становятся заметны только когда ломают сборку. Изменения API не всегда приводят к изменению ABI (и, соответственно, к несовместимости бинарного кода). Как правило, в большинстве случаев (для которых и писалась SharedLibPolicy), изменение ABI происходит при неизменности API, то есть старые пакеты всего лишь надо пересобрать с новыми библиотеками. Бывают также случаи, когда меняется API - то есть становятся несовместимыми devel-пакеты старой и новой библиотек. В таком случае приходится патчить исходный код каждой программы, использующей эту библиотеку, что обычно делается на уровне апстрима. Как правило, апстрим библиотеки при смене API публикует рекомендации по "переезду" со старой версии на новую (обычно сводящуюся к замене имен функций или структур). Также можно рассмотреть случаи, когда изменился API и ABI, но совместимость с приложениями, собранными со старыми версиями библиотек осталась (допустим, была добавлена новая функция, которой не было в старой версии библиотеки). В таком случае правильным будет добавление версионирования символов, и soname менять вообще не надо. В общем, каждый конкретный случай индивидуален, но вот что можно использовать в качестве критерия смены soname: - Изменения соглашения вызова, количества параметров, типа параметров у какой-нибудь из существующих функций. - Изменения структур (добавление/удаление/перемещение/изменение полей структур), используемых библиотекой. - Удаление существующих функций Критерий необходимости каких-то особых действий по смене API: - Удаление полей структур, входящих в публичный API - Удаление (или переименование) макросов или функций, или типов, входящих в публичный API. - Смена сигнатуры вызова функций, изменение количества и типов параметров, типа возвращаемого значения и т.п. В общем, все, что ведет к невозможности пересборки с новой библиотекой без доделки исходного кода приложений. В случае, когда ничего старого не меняется, а добавляется только новое - достаточно только версионирования символов. Все это касается языка С. Для С++ все гораздо хуже, там ABI очень хрупкий, и ломается очень легко, что приводит к необходимости смены soname практически всегда.
next prev parent reply other threads:[~2009-09-28 11:26 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-09-26 20:33 ` Dmitry V. Levin 2009-09-28 8:03 ` REAL 2009-09-28 8:39 ` Sergey Vlasov 2009-09-28 9:49 ` REAL 2009-09-28 9:52 ` Dmitry V. Levin 2009-09-28 10:04 ` Dmitry V. Levin 2009-09-28 10:42 ` REAL 2009-09-28 10:34 ` Damir Shayhutdinov 2009-09-28 10:48 ` Michael Shigorin 2009-09-28 11:06 ` REAL 2009-09-28 10:55 ` Andrey Rahmatullin 2009-09-28 11:26 ` Damir Shayhutdinov [this message] 2009-09-28 11:37 ` Max Ivanov 2009-09-28 11:43 ` Damir Shayhutdinov 2009-09-29 2:57 ` REAL 2009-09-29 8:38 ` Dmitry V. Levin 2009-09-29 9:11 ` REAL 2009-09-28 8:53 ` Boris Savelev
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=679044850909280426h21ff152qed61eaa9f2b31bae@mail.gmail.com \ --to=damir@altlinux.org \ --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