From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <419CC174.3070407@altlinux.ru> Date: Thu, 18 Nov 2004 17:36:20 +0200 From: Andrei Bulava User-Agent: Thunderbird 0.8 (X11/20040913) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Linux Sisyphus discussion list Subject: Re: [sisyphus] lib API changes References: <4199EE2D.1030606@users.sourceforge.net> <200411181552.22110.led@ukr-fin.com.ua> <419CB037.5090403@altlinux.ru> <200411181643.15659.led@ukr-fin.com.ua> In-Reply-To: <200411181643.15659.led@ukr-fin.com.ua> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit 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 15:36:19 -0000 Archived-At: List-Archive: 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-файлов вручную. Так понятнее? -- // AB1002-UANIC