Re: [devel] Re: .a vs .so

[Alexey Morozov <alex-altlinux@idisys.iae.nsk.su>]

[-- Attachment #1: Type: text/plain, Size: 5933 bytes --]

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 для подключения
библиотеки, так и <path>/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

так никуда не деться и в этом случае, так что, выгоды такого решения лично
мне не очень понятны.

Ух... Кажется, всё, лекцию можно заканчивать :-))


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]