From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 11 Jan 2004 21:10:39 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Subject: Re: [devel] Re: .a vs .so Message-ID: <20040111181039.GA18232@nomad.office.altlinux.org> Mail-Followup-To: ALT Devel discussion list References: <20040108134326.GA13308@nomad.office.altlinux.org> <20040108143655.GC2244@pyro.hopawar.private.net> <20040108160330.GA6208@nomad.office.altlinux.org> <20040108161404.GN2244@pyro.hopawar.private.net> <20040108201457.GA28535@nomad.office.altlinux.org> <20040110222311.GB16686@mhz.mikhail.zabaluev.name> <20040111022329.GD12307@localhost.localdomain> <4001614E.20808@l14.ru> <20040111160122.GA18161@nomad.office.altlinux.org> <4001807E.2040602@l14.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <4001807E.2040602@l14.ru> X-fingerprint: 9658 398D 181B 1200 8FC5 26B8 F6F8 846B C1E2 3429 X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 18:10:45 -0000 Archived-At: List-Archive: List-Post: --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sun, Jan 11, 2004 at 07:57:34PM +0300, Алексей Любимов wrote: > Dmitry V. Levin пишет: > >On Sun, Jan 11, 2004 at 05:44:30PM +0300, Алексей Любимов wrote: > > > >>>5. После обнаружения .la-файла, оригинальный (неправленный Альтом) > >>>libtool > >>>использует информацию из dependency_libs для рекурсивного разворачивания > >>>цепочки зависимостей библиотек до самого низа. При этом очевидно, что > >>>при некоторых условиях возможна ситуация, когда одновременно линкеру > >>>передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)). > >>> > >>Вопрос > >>а если в системе стоят только libdb4.0 и libdb4.1, libdb4.1-devel (со > >>статиком) > >>будет подхвачена libdb4.0? > > > >Во время сборки или во время запуска? > > > 1 момент. - Во время сборки. > При отсутствии -devel, разве может программа прилинковаться к библиотеке. Теоретически - да, например, gcc sample.c /lib/libdb-4.1.so -o sample На практике так обычно не линкуются. > >Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L > >- с библиотекой libdb4.0, то во время запуска программы A в памяти > >окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны. > > То, что вся цепочка слинкованных программ должна быть связана с одной > версией libdb4.1 естественно. > Но проблема то поднималась другая. Лишние связи, когда при сборке > программ могут быть подсунуты случайные версии и даже вперемешку. Разве > не так? Разве это другая задача? Как вы сможете отличить случайную линковку от неслучайной? Есть, конечно, некоторые приёмы, которые позволяют определить, используется ли данной программой/библиотекой данная библиотека напрямую. Проще и эффективнее поступить так: если есть источник случайных зависимостей, то его надо закрыть. > Рекурсивно разворачивать во время сборки все связи и завершать сборку > при конфликте версий через другие линкуемые библиотеки имхо совсем > другая задача. не так? Это не задача, это приём, который имеет смысл применить, хотя он и не может выявить всё, например, проблемы, возникающие при динамической загрузке модулей. Предложите, как лучше оформить интерфейс: как описать множество конфликтующих библиотек (который будет меняться), как включать/выключать эту проверку при сборке того или иного пакета. > >>>Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными > >>>Последствиями" для базы rpm, в частности. > >>> > >>А bte зачем делали? > > > >О чём это вы? BTE - это миф. > >Если программа A из предыдущего примера не используется во время сборки > >других пакетов, то выявить её неработоспособность путём пересборки Сизифа > >не удастся. > > > Это совсем из другой оперы. Предлагается то курочить aclocal, то есть > влиять исключительно на процесс сборки. А какой тогда в этом смысл, если > программа в сборке просто не участвует? Кто предлагает курочить aclocal, какая программа не участвует в сборке? Ничего не понял. > Я так понял, что если на этапе сборки не были доступны *.la, то во время > запуска программы хоть эти *la и не участвуют, но проблемы заложенные > недостатком информации при сборке остаются. Я понимаю ситуацию ровно наоборот. Если сборка (динамическая) идёт без .la-файлов, то никакой нехватки информации нет, ни во время сборки, ни во время работы. Фактически, как уже было сказано неоднократно, библиотечные .la-файлы бывают нужны для статической сборки, а модульныке - для динамической загрузки модулей средствами ltdl. > >>>8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5. > >>>libtool подправлен таким образом, чтобы при динамической сборке на > >>>линуксе > >>>список dependency_libs не раскрывался вовсе (при статической все > >>>по-прежнему). > >>>Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере, > >>>вроде бы, решает все остальные. > >>> > >>А почему нельзя на этапе сборки просто ограничить выбор пакетов > >>правильными зависимостями в спеке? Разве это не ограничит выбор > >>dependency_libs? > > > >Вы предлагаете ликвидировать find-requires и перейти на указание > >зависимостей собранных пакетов вручную? > > > Ни разу. Просто в спецслучаях указывать из нескольких альтенатив > (libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие конкурентов. Что такое спецслучаи и кто будет их отлавливать? Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно разные libdb4.X? А если это невозможно? > По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь есть? Есть и будет появляться новое всегда, когда у библиотеки меняется soname. -- ldv --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAAZGf9viEa8HiNCkRAlLeAJ9YyN0kkO6A05XscScU9Qvmbz8mNgCeM/YV jsVfAwROQoMqHTdbShrlmVs= =hgtI -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO--