From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4001807E.2040602@l14.ru> Date: Sun, 11 Jan 2004 19:57:34 +0300 From: =?KOI8-R?Q?=E1=CC=C5=CB=D3=C5=CA_=EC=C0=C2=C9=CD=CF=D7?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20030710 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] Re: .a vs .so References: <3FFC48B3.9020506@l14.ru> <200401081054.01927.ilar@altlinux.ru> <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> In-Reply-To: <20040111160122.GA18161@nomad.office.altlinux.org> X-Enigmail-Version: 0.76.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 16:59:59 -0000 Archived-At: List-Archive: List-Post: 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, разве может программа прилинковаться к библиотеке. > >Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L >- с библиотекой libdb4.0, то во время запуска программы A в памяти >окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны. > > То, что вся цепочка слинкованных программ должна быть связана с одной версией libdb4.1 естественно. Но проблема то поднималась другая. Лишние связи, когда при сборке программ могут быть подсунуты случайные версии и даже вперемешку. Разве не так? Рекурсивно разворачивать во время сборки все связи и завершать сборку при конфликте версий через другие линкуемые библиотеки имхо совсем другая задача. не так? > > >>>Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными >>>Последствиями" для базы rpm, в частности. >>> >>> >>> >>А bte зачем делали? >> >> > >О чём это вы? BTE - это миф. >Если программа A из предыдущего примера не используется во время сборки >других пакетов, то выявить её неработоспособность путём пересборки Сизифа >не удастся. > > Это совсем из другой оперы. Предлагается то курочить aclocal, то есть влиять исключительно на процесс сборки. А какой тогда в этом смысл, если программа в сборке просто не участвует? >>>7.2. Во-вторых, вне зависимости от характера линковки, нам, строго говоря, >>>_необходима_ информация, записанная в dependency_libs. Необходимость >>>этой информации обусловлена [достаточно гипотетической, впрочем] >>>возможностью наличия в зависимостях статической библиотеки без >>>соответствующего динамического аналога (я припоминаю, что, вроде, то ли >>>libkrb, то ли libsocks [некогда] распространялся в таком вот виде). Плюс >>>всякие third-party, но это уже их головная боль, наверное. >>> >>> >>> >>другими словами, даже деление на devel и devel-static с последующей >>неустановкой *-static для сборки программы с динамической линковкой в >>общем случае некорректно? >> >> > >В том случае, о котором идёт речь в 7.2, некорректно. >Правда, у нас в Сизифе таких всего 2: >glibc-devel (libc_nonshared.a и *crt*.o) и gcc (*crt*.o). >И надеюсь, что не будет. > > > >>>7.3. Во-третьих, кроме dependency libs, содержимое .la-файла (конкретно, >>>имя библиотеки) используется libtool'ом для обеспечения корректной работы >>>с ltdl-модулями (см. autobook) >>> >>> >>> >>Предыдущее предположение и здесь в силе? >> >> > >Нет. Во время динамической загрузки можно нормально загрузить только >динамические модули. > > Я так понял, что если на этапе сборки не были доступны *.la, то во время запуска программы хоть эти *la и не участвуют, но проблемы заложенные недостатком информации при сборке остаются. > > >>>8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5. >>>libtool подправлен таким образом, чтобы при динамической сборке на линуксе >>>список dependency_libs не раскрывался вовсе (при статической все >>>по-прежнему). >>>Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере, >>>вроде бы, решает все остальные. >>> >>> >>> >>А почему нельзя на этапе сборки просто ограничить выбор пакетов >>правильными зависимостями в спеке? Разве это не ограничит выбор >>dependency_libs? >> >> > >Вы предлагаете ликвидировать find-requires и перейти на указание >зависимостей собранных пакетов вручную? > > Ни разу. Просто в спецслучаях указывать из нескольких альтенатив (libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие конкурентов. По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь есть?