From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 11 Jan 2004 19:01:22 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Subject: Re: [devel] Re: .a vs .so Message-ID: <20040111160122.GA18161@nomad.office.altlinux.org> Mail-Followup-To: ALT Devel discussion list 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <4001614E.20808@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 16:01:40 -0000 Archived-At: List-Archive: List-Post: --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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? Во время сборки или во время запуска? Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L - с библиотекой libdb4.0, то во время запуска программы A в памяти окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны. > >Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными > >Последствиями" для базы rpm, в частности. > > > А bte зачем делали? О чём это вы? BTE - это миф. Если программа A из предыдущего примера не используется во время сборки других пакетов, то выявить её неработоспособность путём пересборки Сизифа не удастся. > >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) > > > Предыдущее предположение и здесь в силе? Нет. Во время динамической загрузки можно нормально загрузить только динамические модули. > >8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5. > >libtool подправлен таким образом, чтобы при динамической сборке на линуксе > >список dependency_libs не раскрывался вовсе (при статической все > >по-прежнему). > >Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере, > >вроде бы, решает все остальные. > > > А почему нельзя на этапе сборки просто ограничить выбор пакетов > правильными зависимостями в спеке? Разве это не ограничит выбор > dependency_libs? Вы предлагаете ликвидировать find-requires и перейти на указание зависимостей собранных пакетов вручную? -- ldv --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAAXNS9viEa8HiNCkRAuiUAJ4gmRHA5yz01mSAeFzynUOnCkAwdACfRN/5 jB3793xSXMDT1GRuVzP8ezk= =sk8C -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx--