From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 11 Jan 2004 08:23:29 +0600 From: Alexey Morozov To: ALT Devel discussion list Subject: Re: [devel] Re: .a vs .so Message-ID: <20040111022329.GD12307@localhost.localdomain> References: <20040106102757.GK12479@pyro.hopawar.private.net> <20040107163156.GA15124@mhz.mikhail.zabaluev.name> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fXStkuK2IQBfcDe+" Content-Disposition: inline In-Reply-To: <20040110222311.GB16686@mhz.mikhail.zabaluev.name> User-Agent: Mutt/1.4i 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 02:51:46 -0000 Archived-At: List-Archive: List-Post: --fXStkuK2IQBfcDe+ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sun, Jan 11, 2004 at 01:23:11AM +0300, Mikhail Zabaluev wrote: > А можно восстановить чистильщика .la файлов, который помимо удаления > вредных -L будет удалять и -l, которые прописаны в .so. Правда, > по неясному мне принципу в dependency_libs попадают и > .la-файлы. Осмелюсь предположить, что такие зависимости вызваны ленью > и/или недостаточной компетентностью разработчиков upstream, и такие > зависимости можно безжалостно вырезать по принципу "быстрее сломается > -- быстрее исправят". > Не получится ли у нас таким образом и рыбку съесть, и из аквариума > запить? А-А-А... НЕ НАДО ТАК ДЕЛАТЬ!!! В общем, Михаил, вот вкратце задачи и механизм работы libtool. Станет понятен и нынешний конфликт, и возможные пути решения этих проблем. К сожалению, способ, придуманный Вами - не возможный (см. ниже) Введение 1. libtool предназначена для того, чтобы собирать библиотеки и приложения единым, не зависящим в общем случае от возможностей и особенностей target системы, способом и с минимальными отличиями для статических/динамических библиотек 2. Т.к. многообразие систем велико, возможности их различны, то libtool, помимо всего прочего, предоставляет некоторые механизмы, обеспечивающие некоторый "приемлемый уровень" совместимости: в системах, где невозможна динамическая загрузка библиотек в рантайме (aka dlopen), все, что нужно, делается при запуске программы; сохраняется информация о зависимостях библиотек, чтобы можно было использовать их в системах, которые сами не предоставляют такую функциональность (это, между прочим, не только "замшелые уроды, которым пора на свалку истории", но и linux/static libs) итд итп. 3. Нужно отметить, что способы, которыми реализованы все эти возможности, часто вызывают справедливые нарекания со стороны даже понимающих внутреннее устройство libtool пользователей, не говоря уже о "простых парнях, таких как ты и я". Теперь по поводу данной проблемы. 4. В .la-файлах сохраняется, помимо всего прочего, такая информация, как возможные имена библиотеки на диске, список ее зависимостей итп. При этом, libtool в режиме --link может принимать как ключи вида -lsome для подключения библиотеки, так и /libsome.la. Для ключей вида -lsome тоже ведется поиск соответствующего .la-файла и, если он найден, то информации из него отдается предпочтение перед информацией из собственно библиотеки (где этой информации, вообще говоря, может не быть). 5. После обнаружения .la-файла, оригинальный (неправленный Альтом) libtool использует информацию из dependency_libs для рекурсивного разворачивания цепочки зависимостей библиотек до самого низа. При этом очевидно, что при некоторых условиях возможна ситуация, когда одновременно линкеру передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)). Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными Последствиями" для базы rpm, в частности. (В скобках замечу, что многообразие libdb лично у меня вызывает довольно негативную реакцию. С другой стороны, по опыту KSI знаю, что приведение системы в консистентное состояние в данном вопросе приводит к массе усилий, больше напоминающих войну с ветряными мельницами. Зато некоторое время "Все Правильно" :-)) 6. В отсутствие .la-файла libtool, не выпендриваясь, оставляет -lsome в ключах, переданных линкеру, не проводя дальнейший резолвинг подзависимостей. Таким образом, проблема, обозначенная в пункте 5, вроде бы решается при помощи того способа, который был изначально предложен Дмитрием (удаление всех .la-файлов) 7. Однако, на самом деле, это не решение проблемы. 7.1. Во-первых, таким образом (а равно и так, как предложили Вы) мы теряем информацию, потребную для статических сборок, которые доселе можно было проводить простым добавлением флага -static в Makefile.am. 7.2. Во-вторых, вне зависимости от характера линковки, нам, строго говоря, _необходима_ информация, записанная в dependency_libs. Необходимость этой информации обусловлена [достаточно гипотетической, впрочем] возможностью наличия в зависимостях статической библиотеки без соответствующего динамического аналога (я припоминаю, что, вроде, то ли libkrb, то ли libsocks [некогда] распространялся в таком вот виде). Плюс всякие third-party, но это уже их головная боль, наверное. 7.3. Во-третьих, кроме dependency libs, содержимое .la-файла (конкретно, имя библиотеки) используется libtool'ом для обеспечения корректной работы с ltdl-модулями (см. autobook) 8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5. libtool подправлен таким образом, чтобы при динамической сборке на линуксе список dependency_libs не раскрывался вовсе (при статической все по-прежнему). Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере, вроде бы, решает все остальные. К сожалению, это решение привносит необходимость обязательного libtoolize --copy --force; aclocal ....; autoconf; при сборке пакета, что не всегда приемлемо для "The Real World" software в силу /разных факторов/. 8.1. Мной добавлен патчик, который позволяет отказаться от запуска aclocal ...; autoconf по крайней мере, для пакетов, которые подготавливались к распространению в системах с libtool-1.5. 8.2. К сожалению, пакетов, использующих более старые версии libtool (как правило, 1.4), довольно много. Для таких пакетов и предложено проводить синхронный апдейт aclocal макросов при помощи aclocal ...; autoconf. См. п. 8 о нежелательности таких манипуляций. 9. Сейчас Дмитрием предложена схема, когда .la-файлы сохраняются, однако информация о dependency_libs из них [как правило] удаляется, а в случае необходимости (для статических сборок, н-р), насчитывает на основании зависимостей динамических аналогов статических библиотек. В принципе, конечно, можно и так, но, по ощущениям, от обязательного libtoolize --copy --force так никуда не деться и в этом случае, так что, выгоды такого решения лично мне не очень понятны. Ух... Кажется, всё, лекцию можно заканчивать :-)) --fXStkuK2IQBfcDe+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAALOhX5DZdJn19V0RAtyYAJ4+nRyR3EhPrK0eIpsnz1KQcdckAQCghrZm rRWQBmCMrQNYAOX2MI0/SxY= =Rnrq -----END PGP SIGNATURE----- --fXStkuK2IQBfcDe+--