From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: led@ukr-fin.com.ua To: ALT Linux Sisyphus discussion list Subject: Re: [sisyphus] lib API changes Date: Thu, 18 Nov 2004 18:06:42 +0200 User-Agent: KMail/1.6.2 References: <4199EE2D.1030606@users.sourceforge.net> <200411181643.15659.led@ukr-fin.com.ua> <419CC174.3070407@altlinux.ru> In-Reply-To: <419CC174.3070407@altlinux.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Message-Id: <200411181806.42430.led@ukr-fin.com.ua> X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2004 16:06:45 -0000 Archived-At: List-Archive: В сообщении от Четверг 18 Ноябрь 2004 17:36 Andrei Bulava написал(a): > led@ukr-fin.com.ua пишет: > > В сообщении от Четверг 18 Ноябрь 2004 16:22 Andrei Bulava написал(a): > >>led@ukr-fin.com.ua пишет: > >>>Например, libXaw.so.8 > >> > >>Что в этом криминального? В ALM 2.4 libXaw.so.7, в текущем Sisyphus - > >>libXaw.so.8. Если авторы xorg изменили ABI этой библиотеки (и поменяли > >>soname вследствие этого), то всё абсолютно корректно - приложения, > >>слинкованные с libXaw.so.8 с большой долей вероятности будут иметь > >>unresolved symbols при попытке запуска в системе с libXaw.so.7. > >> > >>При этом API могло и не менятся, т.е. пересборка в среде с libXaw.so.7 > >>тех же самых приложений пройдёт корректно. Но они будут > >>двоично-несовместимы уже с сизифной libXaw.so.8. > > > > А вот здесь поподробнее, плиз... Кто "они", и что значит "будут > > двоично-несовместимы"? Там что - вызовы из libXaw.so по абсолютному > > адресу происходят? > > Попытаюсь объяснить на пальцАх (подробнее можно прочитать в упомянутом > надцать раз "How to Write Shared Libraries"). > > Есть библиотека libfoo.so (это soname - попадаются и такие библиотеки!) > с API из единственной функции bar ( int ) и есть приложение с вызовом > функции bar ( x ), динамически слинкованное с библиотекой libfoo.so. В > один прекрасный день девелоперы libfoo решают, что надо изменить > сигнатуру функции bar с bar ( int ) на bar ( int, int ), при этом старая > функция bar ( int ) теперь выражается через bar ( int, int ) как bar ( > int, <константа >). Естественно, чтобы не ломать API, в заголовочных > файлах libfoo добавляется макрос, подменяющий на этапе препроцессинга > все вызовы bar ( x ) на bar ( x, <константа> ) - это даёт гарантию, что > приложения с вызовом bar ( x ) будут без проблем компилироваться с > "новой" libfoo.so. > > Вот и имеем изменение ABI в то время как API "новой" libfoo.so есть > надмножество API "старой" libfoo.so: теперь приложение, динамически > слинкованное со "старой" libfoo.so, при запуске с "новой" libfoo.so > будет иметь неразрешённый символ - ибо двоичный файл "новой" библиотеки > вообще не содержит функции bar ( int ) !!! И наоборот - если > перекомпилировать приложение с "новой" libfoo.so - оно не запустится со > старой, теперь из-за отсутствия функции bar ( int, int ) !!! > > Вот тогда и было придумано соглашение о добавлении в soname цифр, > отражающих изменение ABI, чтобы избежать появления dll hell. Это даёт > возможность менеджерам пакетов автоматически отслеживать двоичную > целостность системы без запуска всех исполняемых ELF-файлов вручную. > > Так понятнее? Это понятно:) Вопрос не в терминологии, а в практике: т.н. "автоматика" поставила зависимость на libXaw.so.8. Вы уверены, что это правильно? ИМХО нет... Led.