From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4001CC66.60004@l14.ru> Date: Mon, 12 Jan 2004 01:21:26 +0300 From: Alexey Lubimov User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.3) Gecko/20030331 X-Accept-Language: ru, ru-ru MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] Re: .a vs .so 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> <20040111181039.GA18232@nomad.office.altlinux.org> In-Reply-To: <20040111181039.GA18232@nomad.office.altlinux.org> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit 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 22:21:31 -0000 Archived-At: List-Archive: List-Post: Dmitry V. Levin пишет: > 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 Это да. Только по моему перед библиотекой ключик -lm нужен. > > На практике так обычно не линкуются. По моему так линкуют только личные библиотеки из своего же состава и то нечасто. > > >>>Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L >>>- с библиотекой libdb4.0, то во время запуска программы A в памяти >>>окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны. >> >>То, что вся цепочка слинкованных программ должна быть связана с одной >>версией libdb4.1 естественно. >>Но проблема то поднималась другая. Лишние связи, когда при сборке >>программ могут быть подсунуты случайные версии и даже вперемешку. Разве >>не так? > > > Разве это другая задача? Если речь идет именно о сборке программ в отдельном окружении без конкурирующих пакетов - да. В этом случае, есть "дефолтная" libdb4.0 и есть "несовместимая с ней альтернатива" libdb4.1 Программы собираются с libdb4.1 Если программа требует именно libdb4-compat4.0, то она собирается с ним и помечается, как libdb4-incompatible (на самом деле само по себе buidrequires на libdb4-compat4.0 и будет этим признаком). При операции релиза (типа sandcl endpocket sisyphus) репозитария можно хоть полдня ползать по репозитарию скриптами, раскрывая цепочки зависимостей (buildrequires - они железные и проверены в bte) пакетов и проверяя получившийся ряд на смешивание в них запрещеных сочетаний libdb. > > Как вы сможете отличить случайную линковку от неслучайной? Никак. Это как в случае с мотоциклами. Сначала удаляют "лишний метал" со ступицы, а потом теряют тормоза от перегрева. Чтобы определить случайность линковки в общем случае, надо протестировать программу по полной программе. Имхо, сизиф страдает от таких "оптимизаций" поболее, чем от их отсутствия. У программ есть авторы и они обычно пишут список зависимостей. Далее второе (расширяющее) приближение - сборка. На этом все начные методы заканчиваются иначинается либо гадание либо тупая ручная статистика учета возникших от оптимизации проблем. Есть БТЕ. Вот пусть он и отсекает 100% лишнее. Остальное в сизифе просто не реализуемо в принципе. > Есть, конечно, некоторые приёмы, которые позволяют определить, > используется ли данной программой/библиотекой данная библиотека напрямую. ldd? имхо не слишком надежно. > > Проще и эффективнее поступить так: > если есть источник случайных зависимостей, то его надо закрыть. ага. только не уничтожать при этом пакеты. а выборочно загружать в бте. > > >>Рекурсивно разворачивать во время сборки все связи и завершать сборку >>при конфликте версий через другие линкуемые библиотеки имхо совсем >>другая задача. не так? > > > Это не задача, это приём, который имеет смысл применить, хотя он и не > может выявить всё, например, проблемы, возникающие при динамической > загрузке модулей. > > Предложите, как лучше оформить интерфейс: как описать множество > конфликтующих библиотек (который будет меняться), как включать/выключать > эту проверку при сборке того или иного пакета. Я вижу это таким образом. Должна быть практически не меняющаяся по именам умолчальная среда с одним претендентом по каждой альтернативе. один gcc, glibc, libpng, libdb4 etc Альтернативы должны имет звания gcc-compat2.96 glibc-compat2.3 libng-compat2 libdb5-compat0 etc Замечу, что основные имена являются скользящими. То есть libpng когда то было версии 2, а потом без изменения имени становится версии3, а вот -compat уже ссылаются на определенную версию и заморожены в таком состоянии. пакеты в нормальном состоянии должны требовать в BuildRequires gcc, glibc, libpng, libdb4. Если пакет перестает собираться с новой версией и начинает требовать -compat, то в BuildRequires вручную ставится зависимость на конкретный compat. Зависимость на -compat и является признаком замороженного на версии пакета. Пишуться правила типа libdb conflicts libdb-compat При пересборке факт смешанного использования библиотек через третью программ не ловится. Его даже и ловить не надо. После пересборки репозитария, по нему запускается скрипт проверки, рекурсивно разворачивает зависимости и по правилам ловит факт смешивания конфоиктующих альтернатив. После этого майнтейнеры решают, что делать. То ли выбросить что либо из репозитария, то ли пересобрать по другому. > >>>>>Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными >>>>>Последствиями" для базы rpm, в частности. >>>>> >>>> >>>>А bte зачем делали? >>> >>>О чём это вы? BTE - это миф. >>>Если программа A из предыдущего примера не используется во время сборки >>>других пакетов, то выявить её неработоспособность путём пересборки Сизифа >>>не удастся. >>> >> >>Это совсем из другой оперы. Предлагается то курочить aclocal, то есть >>влиять исключительно на процесс сборки. А какой тогда в этом смысл, если >>программа в сборке просто не участвует? > > > Кто предлагает курочить aclocal, какая программа не участвует в сборке? > Ничего не понял. модифицированный libtoolize Морозов предложил запускать вместо aclocal. при сборке может отсутствовать та, третья программа, через которую библиотеки и конфликтуют. Вот эта, которая L: -------------- >>>Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L >>>- с библиотекой libdb4.0, то во время запуска программы A в памяти >>>окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны. >> -------------- > > >>Я так понял, что если на этапе сборки не были доступны *.la, то во время >>запуска программы хоть эти *la и не участвуют, но проблемы заложенные >>недостатком информации при сборке остаются. > > > Я понимаю ситуацию ровно наоборот. > Если сборка (динамическая) идёт без .la-файлов, то никакой нехватки > информации нет, ни во время сборки, ни во время работы. > > Фактически, как уже было сказано неоднократно, библиотечные .la-файлы > бывают нужны для статической сборки, а модульныке - для динамической > загрузки модулей средствами ltdl. Да пока что вы противоречите друг другу с Морозовым, а я просто не знаю, кто из вас прав :( >>Ни разу. Просто в спецслучаях указывать из нескольких альтенатив >>(libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие конкурентов. > > > Что такое спецслучаи и кто будет их отлавливать? майнтейнер. прога то либо не будет собираться, либо работать. > Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно > разные libdb4.X? А если это невозможно? В бте? такие случаи автоматом не решаются. Придется собирать консилиум майнтейнеров и решать, кого убрать. Как сегодня и происходит. >>По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь есть? > > > Есть и будет появляться новое всегда, когда у библиотеки меняется soname. Не так. Это когда библиотеки обновляюти вместе с тем под другим именем оставляют старые версии. Если библиотеки просто обновляют, то либо прога собирается с ней, либо нет, но левых зависимостей все равно не возникает.