[sisyphus] Возвращаясь к напечатанному (про .la)

[Alexey Morozov]

On Thu, Dec 11, 2003 at 05:30:42PM +0300, Dmitry V. Levin wrote:
> > Вот этого, честно говоря, не понял. Точнее, понятно, что такую проверку
> > _корректнее_ проводить в числе остальных прочих проверок способностей
> > линкера/платформы, но это совсем не _обязательно_.
> Как провести инициализацию link_all_deplibs=no в ltmain.sh (а не а
> libtool.m4) таким образом, чтобы патч взяли в upstream?
На самом деле, там все сложнее. Этот самый link_all_deplibs играет не
основную роль (из-за чего, собственно, и патчить приходится). Поэтому
дело скорее не в инициализации, а в неиспользовании этого параметра
должным образом (скорее всего, в силу ущербности/ошибочности реализации
логики)

Я трейсил все это дело, в решающий момент (то есть, в этой самой
проверке, после которой Ваш патч уводит на else continue),
$link_all_deplibs оказывается равным no, причем, даже в случае -static
что, впрочем, не мешает libtool'у все равно зацепить $dependency_libs.

> > Вообще, мне кажется, в данном случае, слона лучше есть по кусочкам.
> > То есть, пропихнуть (дополненный проверкой архитектуры) патч в libtool,
> В libtool-1.5-alt-link_all_deplibs.patch с проверкой архитектуры всё
> вроде бы нормально.
Вероятно, за исключением того, что Вы делаете ее в libtool.m4, что
автоматически приводит к необходимости aclocal/autoconf

> > в принципе, представляется задачей реальной.
> Да, представляется.  Продвижение правильных патчей в upstream занимает у
> меня время, сравнимое с их изготовлением.
:-) Дорогу осилит, и все такое прочее :-).

> 
> > Установить принудительный
> > libtoolize --force тоже реально (проблемы могут быть только у
> > действительно проблемных пакетов, но эти проблемы, _вероятнее всего_, можно
> > продемонстрировать автору безотносительно данной темы), корректно
> > написанные программы такую операцию точно переживут (обязаны)
> Вашими бы словами...
Нет, на самом деле. Мы же исходим из того, что люди вменяемы, правда?
:-)

> 
> > На втором этапе, когда патч в libtool _уже_ будет, можно будет
> > разговаривать с autoconf'овыми господами на предмет: а не включить ли
> > нам такую замечательную фичу, чтобы-де не руками или автоугадавом, а
> > "правильно", в числе остальных ./configure'нных проверок способностей
> > линкера?
> А при чём тут autoconf'овые господа?
Разве проверка способностей линкера - это, в конечном итоге, не их вотчина?

> > > Я точно знаю, что не все пакеты-пользователи libtool переживут
> > > libtoolize --force (что необходимо даже в случае хака в виде патча на
> > Я предлагаю составить и огласить их список. Если делать эту операцию
> > итеративно, то возни будет явно меньше, чем с вычищением .la отовсюду.
> Думаю что больше.
Она будет, она будет каждый раз немного другая, но она не потребует
моментального пересбора всего и вся.

> > > ltmain.sh), а тех, кто выдержит ещё и aclocal с autoconf, будет ещё
> > > меньше.
> > А вот с этим, видимо, лучше обождать.
> Тогда см. вопрос #2.
Ну, мне кажется, здесь нет проблемы, если [на первом этапе] проверкой
возможностей линкера занимается код, включенный в ltmain.sh.

> 
> > Надо? Нет, правда, если это надо, и если это избавит меня от необходимости
> > перебирать те пакеты, для которых мне актуальна статическая линковка -
> > я его сделаю. Миграция на другую платформу для девелопмента пока выглядит
> > более затратным решением.
> У меня нет ответа на этот вопрос.
Нет, реально есть приложения, которым вынь да полож libtool-1.4?

> За что вы так любите статические библиотеки? :)
Мы не любим. Но нам приходится собирать статические (ужас! ужас!
_полностью_ статические) приложения, без каких-либо внешних зависимостей.
Типа, желание кастомера - закон, и все такое прочее.

Но, возвращаясь к нашим баранам: в дополнение к существующей правке на
ltmain.sh предлагается также включить туда (в ltmain.sh) код по проверке
архитектуры/линкера, и выявить тех, кто не переживет libtoolize --force.
Последнее достигается следующими мерами

1. Временным исправлением макроса %configure так, чтобы libtoolize
--force запускался вне зависимости от неопределенного __libtoolize
2. Батч-пересборкой _программ_, использующих макрос %configure, с
определением, кого расплющило
3. Батч-пересборкой программ, которые напрямую используют ./configure.
С этими придется помучаться, но, думаю, счастье возможно, нужно только
подумать, как именно сделать.

Впрочем, специальную пересборку можно и не проводить, пустив все на самотек:
когда понадобится, тогда и пересоберется. Или сломается, тогда и глядеть
на него. План?

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/sisyphus/attachments/20031211/4881d3af/attachment-0009.bin>