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

[Dmitry V. Levin]

On Thu, Dec 11, 2003 at 07:51:17PM +0600, Alexey Morozov wrote:
> On Thu, Dec 11, 2003 at 03:02:11PM +0300, Dmitry V. Levin wrote:
> > Я уже частично ответил "в давешнем письме".
> > 
> > Корректный патч на libtool, который бы активировал поддержку
> > link_all_deplibs только для GNU/Linux (где это действительно нужно и
> > работает), должен быть таким (или примерно таким) как
> > libtool-1.5-alt-link_all_deplibs.patch - только в этом случае можно
> > рассчитывать на "вправить мозги их авторам".
> Да, конечно. BTW, в моем хаке есть проверка $host на *-*linux-*.

Это хорошо.

> > В именно, включение link_all_deplibs должно происходить не в ltmain.sh,
> > а в AC_LIBTOOL_PROG_LD_SHLIBS, который определён в libtool.m4 и для
> Вот этого, честно говоря, не понял. Точнее, понятно, что такую проверку
> _корректнее_ проводить в числе остальных прочих проверок способностей
> линкера/платформы, но это совсем не _обязательно_.

Как провести инициализацию link_all_deplibs=no в ltmain.sh (а не а
libtool.m4) таким образом, чтобы патч взяли в upstream?

> > корректного попадания link_all_deplibs=no в $topdir/libtool необходимо
> > обновить configure, т.е. это требует запуска как минимум
> > libtoolize --force, aclocal, и autoconf --force.
> Зачем --force?
> Вообще, мне кажется, в данном случае, слона лучше есть по кусочкам.
> То есть, пропихнуть (дополненный проверкой архитектуры) патч в libtool,

В libtool-1.5-alt-link_all_deplibs.patch с проверкой архитектуры всё
вроде бы нормально.

> в принципе, представляется задачей реальной.

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

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

Вашими бы словами...

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

А при чём тут autoconf'овые господа?

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

Думаю что больше.

> > ltmain.sh), а тех, кто выдержит ещё и aclocal с autoconf, будет ещё
> > меньше.
> А вот с этим, видимо, лучше обождать.

Тогда см. вопрос #2.

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

У меня нет ответа на этот вопрос.

> > Поэтому я выбрал "вариант 1" в терминологии "давешнего письма" - он
> Эко Вас зацепила фраза :-)
> > реальнее и дешевле.
> Реальнее - да, наверное. Дешевле - вопрос, если, конечно, оценивать
> потери в совокупности. Ну и потом, если помните, я однажды уже задавал
> [Вам] вопрос: "собирается ли Альт двигать в жизнь _правильные_ решения,
> даже если...?" Тогда мне был дан ответ: "Да, собирается" :-).
> Представляется неплохой шанс ;-)

За что вы так любите статические библиотеки? :)


-- 
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/a0d727d6/attachment-0009.bin>