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

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

[Alexey Morozov]

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

В общем и целом, меня, как многие, наверное, уже догадались :-),
совершенно не устроила идея лечения [хронической] мигрени путем
отстреливания головного мозга.

В итоге, я немного посидел над ltmain.sh и, _такое ощущение_, что
у меня есть _хак_ на libtool, который, с одной стороны, позволяет собирать
разделяемые библиотеки без влинковывания всего, что в них движется,
с другой, _кажется_, сохраняет возможность статической сборки
[приложений] одним единственным движением (точнее, флагом в _LDFLAGS).
Статус у всего этого дела, как обычно, "works for me", причем, я даже
еще не вполне уверен, что works (приложение собралось, какие-то
простейшие тесты на libtool'овую функциональность отработали, но сказать
уверенно, что все возможности libtool покрываются, я сейчас не могу.

Если это интересно еще кому-нибудь кроме горстки отщепенцев, я отдам
этот хак. Вполне возможно, его удастся пропихнуть в основную либтуловую
ветку, я старался обойтись минимумом изменений.

С уважением, Алексей Морозов.


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

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

[Dmitry V. Levin]

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

On Wed, Dec 10, 2003 at 10:04:08PM +0600, Alexey Morozov wrote:
> В общем и целом, меня, как многие, наверное, уже догадались :-),
> совершенно не устроила идея лечения [хронической] мигрени путем
> отстреливания головного мозга.
> 
> В итоге, я немного посидел над ltmain.sh и, _такое ощущение_, что
> у меня есть _хак_ на libtool, который, с одной стороны, позволяет собирать
> разделяемые библиотеки без влинковывания всего, что в них движется,
> с другой, _кажется_, сохраняет возможность статической сборки
> [приложений] одним единственным движением (точнее, флагом в _LDFLAGS).
> Статус у всего этого дела, как обычно, "works for me", причем, я даже
> еще не вполне уверен, что works (приложение собралось, какие-то
> простейшие тесты на libtool'овую функциональность отработали, но сказать
> уверенно, что все возможности libtool покрываются, я сейчас не могу.
> 
> Если это интересно еще кому-нибудь кроме горстки отщепенцев, я отдам
> этот хак. Вполне возможно, его удастся пропихнуть в основную либтуловую
> ветку, я старался обойтись минимумом изменений.

А разве libtool-1.5-alt-link_all_deplibs.patch из libtool_1.5-1.5-alt10 не
достаточно?


-- 
ldv

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

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

[Sergey S. Skulachenko]

On Wed, 10 Dec 2003 19:16:58 +0300
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

> А разве libtool-1.5-alt-link_all_deplibs.patch из
> libtool_1.5-1.5-alt10 не достаточно?

Всю неделю жестоко болею гриппом. До клавиатуры с трудом
доползаю. Иносказательной речи совсем не понимаю, юмора - тоже.
Может мне кто-нибудь _это_ перевести? Можно личным письмом, так
как я уверен, что остальным всё понятно. А понять хочется.

-- 
С уважением,
С.С.Скулаченко

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

[Alexey Morozov]

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

On Wed, Dec 10, 2003 at 07:16:58PM +0300, Dmitry V. Levin wrote:
> > Если это интересно еще кому-нибудь кроме горстки отщепенцев, я отдам
> > этот хак. Вполне возможно, его удастся пропихнуть в основную либтуловую
> > ветку, я старался обойтись минимумом изменений.
> А разве libtool-1.5-alt-link_all_deplibs.patch из libtool_1.5-1.5-alt10 не
> достаточно?
Ну, у меня чуть-чуть по-другому, более /громоздко/, но, видимо, и
альтовый вариант вполне должен работать [для большинства случаев, по
крайней мере]. Но тогда возникает следующий вопрос: если все так
замечательно, и решение той проблемы, которую Вы описывали в давешнем
письме, _уже_ существует, то зачем тогда все эти ужасы с пересборкой
половины Сизифа и _реальным_ кастрированием имеющейся функциональности
(libtool как бы и есть, да только толку в нем чуть, все равно, всё руками
приходится делать)?

Имеется ли статистика по приложениям, которые сломаются после
libtoolize --force? И не проще ли вправить мозги их авторам, если
это необходимо, чем сознательно плодить линух-онли (хуже того,
distribution-only) затычки, которые потребуют доп. затычек?

Или, "я не знаю, о чем ви тут г'овор'ите, но ехать таки надо"?


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

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

[Sergey S. Skulachenko]

On Thu, 11 Dec 2003 03:20:18 +0600
Alexey Morozov <alex-altlinux@idisys.iae.nsk.su> wrote:

> Имеется ли статистика по приложениям, которые сломаются после
> libtoolize --force?

А если --force не достаточно, то кому нужна эта статистика?

Кстати, для интереса я пособирал Ваш
gtk-engines_1x-0.12-alt2.src.rpm. Так, не идет сборка без ручного
вмешательства.

-- 
С уважением,
С.С.Скулаченко

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

[Alexey Morozov]

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

On Thu, Dec 11, 2003 at 09:54:16AM +0300, Sergey S. Skulachenko wrote:
> On Thu, 11 Dec 2003 03:20:18 +0600
> Alexey Morozov <alex-altlinux@idisys.iae.nsk.su> wrote:
> 
> > Имеется ли статистика по приложениям, которые сломаются после
> > libtoolize --force?
> А если --force не достаточно, то кому нужна эта статистика?
Не понял вопроса. Статистика нужна, чтобы понять, скольки человекам
придется объяснять, как пользоваться libtool'ом. Потому как поддерживать
это кривое <censored> самостоятельно мне совсем не улыбается.

На самом деле, одно такое приложение - как раз gtk-engines_1x, где
libtool'овые макросы [были] впихнуты в acinclude.m4. Разумеется, как
только изменилась configure, которая генерит libtool из ltmain.sh, вся
эта машинерия накрылась.

> Кстати, для интереса я пособирал Ваш
> gtk-engines_1x-0.12-alt2.src.rpm. Так, не идет сборка без ручного
> вмешательства.
Что именно не работает? Пишите, буду разбираться. Как я уже говорил,
все, что я где-либо выкладывааю имеет статус "works for me", поэтому
возможны недоразумения. 


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

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

[Alexey Morozov]

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

On Thu, Dec 11, 2003 at 03:22:24PM +0600, Alexey Morozov wrote:
> > Кстати, для интереса я пособирал Ваш
> > gtk-engines_1x-0.12-alt2.src.rpm. Так, не идет сборка без ручного
> > вмешательства.
> Что именно не работает? Пишите, буду разбираться. Как я уже говорил,
> все, что я где-либо выкладывааю имеет статус "works for me", поэтому
> возможны недоразумения. 
Посмотрите сообщение про "куда уехал /usr/lib/libgmodule.la"


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

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

[Dmitry V. Levin]

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

On Thu, Dec 11, 2003 at 03:20:18AM +0600, Alexey Morozov wrote:
> On Wed, Dec 10, 2003 at 07:16:58PM +0300, Dmitry V. Levin wrote:
> > > Если это интересно еще кому-нибудь кроме горстки отщепенцев, я отдам
> > > этот хак. Вполне возможно, его удастся пропихнуть в основную либтуловую
> > > ветку, я старался обойтись минимумом изменений.
> > А разве libtool-1.5-alt-link_all_deplibs.patch из libtool_1.5-1.5-alt10 не
> > достаточно?
> Ну, у меня чуть-чуть по-другому, более /громоздко/, но, видимо, и
> альтовый вариант вполне должен работать [для большинства случаев, по
> крайней мере]. Но тогда возникает следующий вопрос: если все так
> замечательно, и решение той проблемы, которую Вы описывали в давешнем
> письме, _уже_ существует, то зачем тогда все эти ужасы с пересборкой
> половины Сизифа и _реальным_ кастрированием имеющейся функциональности
> (libtool как бы и есть, да только толку в нем чуть, все равно, всё руками
> приходится делать)?

Я уже частично ответил "в давешнем письме".

Корректный патч на libtool, который бы активировал поддержку
link_all_deplibs только для GNU/Linux (где это действительно нужно и
работает), должен быть таким (или примерно таким) как
libtool-1.5-alt-link_all_deplibs.patch - только в этом случае можно
рассчитывать на "вправить мозги их авторам".

В именно, включение link_all_deplibs должно происходить не в ltmain.sh,
а в AC_LIBTOOL_PROG_LD_SHLIBS, который определён в libtool.m4 и для
корректного попадания link_all_deplibs=no в $topdir/libtool необходимо
обновить configure, т.е. это требует запуска как минимум
libtoolize --force, aclocal, и autoconf --force.

Я точно знаю, что не все пакеты-пользователи libtool переживут
libtoolize --force (что необходимо даже в случае хака в виде патча на
ltmain.sh), а тех, кто выдержит ещё и aclocal с autoconf, будет ещё
меньше.
На а патча на libtool-1.4, который вообще не поддерживает нормально
link_all_deplibs, у меня нет.

Поэтому я выбрал "вариант 1" в терминологии "давешнего письма" - он
реальнее и дешевле.


-- 
ldv

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

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

[Alexey Morozov]

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

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 в $topdir/libtool необходимо
> обновить configure, т.е. это требует запуска как минимум
> libtoolize --force, aclocal, и autoconf --force.
Зачем --force?
Вообще, мне кажется, в данном случае, слона лучше есть по кусочкам.
То есть, пропихнуть (дополненный проверкой архитектуры) патч в libtool,
в принципе, представляется задачей реальной. Установить принудительный
libtoolize --force тоже реально (проблемы могут быть только у
действительно проблемных пакетов, но эти проблемы, _вероятнее всего_, можно
продемонстрировать автору безотносительно данной темы), корректно
написанные программы такую операцию точно переживут (обязаны)

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

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

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


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

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


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

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

[Dmitry V. Levin]

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

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

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

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

[Alexey Morozov]

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

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.
С этими придется помучаться, но, думаю, счастье возможно, нужно только
подумать, как именно сделать.

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


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

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

[Alexey Tourbin]

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

On Thu, Dec 11, 2003 at 09:19:51PM +0600, Alexey Morozov wrote:
> Нет, на самом деле. Мы же исходим из того, что люди вменяемы, правда?
> :-)

Увы, на всё множестве это не выполняется.

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

Ужас, но мне кажется это достаточным основанием для того, чтобы система,
ориентированная на динамические библиотеки, тем не менее полностью
поддерживала корректную статическую линковку.  Поэтому автоматическое
удаление .la файлов кажется мне неправильным решением.  Disclaimer:
вопрос об альтернативных решениях я не прорабатывал.

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

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

[Alexey Morozov]

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

On Fri, Dec 12, 2003 at 05:19:41PM +0300, Alexey Tourbin wrote:
> On Thu, Dec 11, 2003 at 09:19:51PM +0600, Alexey Morozov wrote:
> > Нет, на самом деле. Мы же исходим из того, что люди вменяемы, правда?
> Увы, на всё множестве это не выполняется.
Ну, нам и неинтересны _все_ люди (в данном контексте, по крайней мере).
А поддерживать программный продукт невменяемого автора - задача, как мне
кажется, бесперспективная.

> > Мы не любим. Но нам приходится собирать статические (ужас! ужас!
> > _полностью_ статические) приложения, без каких-либо внешних зависимостей.
> > Типа, желание кастомера - закон, и все такое прочее.
> Ужас, но мне кажется это достаточным основанием для того, чтобы система,
> ориентированная на динамические библиотеки, тем не менее полностью
> поддерживала корректную статическую линковку.  Поэтому автоматическое
Да, это, по-моему, вещь необходимая, учитывая многообразие и
изменчивость линуксового (глибсишного и не только) API. Собственно, я
наступал на грабли со _скрытой_ неработоспособностью _некоторых_
библиотек (из комплекта TAO) при переезде с glibc-2.9x.y (из релизного
RH-8.0) на RH8.0 же glibc, но из errata (по состоянию на март месяц).
То есть, все как настоящее, только запросы _втихую_ перестают маршаллиться.
Пересборка либы (ACE/TAO) с новой glibc лежит положение.
Спрашивается: кто виноват и что делать :-)

> удаление .la файлов кажется мне неправильным решением.  Disclaimer:
> вопрос об альтернативных решениях я не прорабатывал.
Ну, собственно, я и затеял этот флейм, чтобы обсудить с Дмитрием
альтернативные варианты. Может, и договоримся до чего...




> _______________________________________________
> Sisyphus mailing list
> Sisyphus@altlinux.ru
> http://altlinux.ru/mailman/listinfo/sisyphus


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

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

[Dmitry V. Levin]

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

On Thu, Dec 11, 2003 at 09:19:51PM +0600, Alexey Morozov wrote:
> 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.

Т.е. мой патч не работает?


-- 
ldv

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

Re: [sisyphus] Обнаружены новые враги народа! (was: Возвращаясь ...)

[Alexey Morozov]

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

On Mon, Dec 15, 2003 at 04:59:33PM +0300, Dmitry V. Levin wrote:
> > Я трейсил все это дело, в решающий момент (то есть, в этой самой
> > проверке, после которой Ваш патч уводит на else continue),
> > $link_all_deplibs оказывается равным no, причем, даже в случае -static
> > что, впрочем, не мешает libtool'у все равно зацепить $dependency_libs.
> Т.е. мой патч не работает?
Он работает. Но работает не столько потому что Вы патчите libtool.m4, а
потому что Вы патчите ltmain.sh, не давая ему проскакать по списку
$dependency_libs (строка 2150 и ниже). А это, кстати, можно сделать, и не
трогая libtool.m4.

P.S. Кстати, есть еще одна довольно-таки неприятная проблема: pkgconfig

Пример:

alex@pyro ~/tmp/libtool $ rpm -q libtool_1.5 libgtk+2
libtool_1.5-1.5-alt10
libgtk+2-2.2.4-alt4
alex@pyro ~/tmp/libtool $ libtool --mode=link gcc -g -O -o test test.o
-lgtk-x11-2.0
gcc -g -O -o test test.o  -lgtk-x11-2.0
alex@pyro ~/tmp/libtool $ _

Все, как видите, вполне корректно, и именно так, как хотелось бы
(причем, даже если ЕСТЬ .la-файлы, у меня, на самом деле, штатно стоит
самосборанная libgtk+2, c .la-файлами, отличие только в способе передачи
аргументов от libtool к gcc). Если пользоваться pkgconfig, то все становится
гораздо грустнее:

alex@pyro ~/tmp/libtool $ libtool --mode=link gcc -g -O -o test test.o
`pkg-config --libs gtk+-2.0`
gcc -g -O -o test test.o -Wl,--export-dynamic  -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0
-lpango-1.0 /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so -ldl
/usr/lib/libglib-2.0.so
alex@pyro ~/tmp/libtool $ _

Видите? Все мучения с выкидыванием "лишних" .la файлов оказались тщетны.
pkgconfig все равно вычислил всех, на кого так или иначе ссылается
gtk-x11-2.0 и подсунул соответствующие параметры libtool'у.

Или следующим шагом будет искоренение pkgconfig? :-) Давайте тогда с
самого начала огласим полный список тех, кто идет против трудового
народа? Может, трудовому народу покажется, что проще самому
повернуть в другую сторону? :-)


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

Re: [sisyphus] Обнаружены новые враги народа! (was: Возвращаясь ...)

[Dmitry V. Levin]

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

On Tue, Dec 16, 2003 at 06:16:48PM +0600, Alexey Morozov wrote:
> On Mon, Dec 15, 2003 at 04:59:33PM +0300, Dmitry V. Levin wrote:
> > > Я трейсил все это дело, в решающий момент (то есть, в этой самой
> > > проверке, после которой Ваш патч уводит на else continue),
> > > $link_all_deplibs оказывается равным no, причем, даже в случае -static
> > > что, впрочем, не мешает libtool'у все равно зацепить $dependency_libs.
> > Т.е. мой патч не работает?
> Он работает. Но работает не столько потому что Вы патчите libtool.m4, а
> потому что Вы патчите ltmain.sh, не давая ему проскакать по списку
> $dependency_libs (строка 2150 и ниже). А это, кстати, можно сделать, и не
> трогая libtool.m4.

У вас есть патч, который делает это лучше?  Так давайте его сюда.

> P.S. Кстати, есть еще одна довольно-таки неприятная проблема: pkgconfig

Да, конечно.  Но
1. пользователей pkgconfig меньше;
2. нельзя объять необъятное;
3. до исправления pkgconfig очередь тоже дойдёт. :)

> Пример:
> 
> alex@pyro ~/tmp/libtool $ rpm -q libtool_1.5 libgtk+2
> libtool_1.5-1.5-alt10
> libgtk+2-2.2.4-alt4
> alex@pyro ~/tmp/libtool $ libtool --mode=link gcc -g -O -o test test.o
> -lgtk-x11-2.0
> gcc -g -O -o test test.o  -lgtk-x11-2.0
> alex@pyro ~/tmp/libtool $ _
> 
> Все, как видите, вполне корректно, и именно так, как хотелось бы
> (причем, даже если ЕСТЬ .la-файлы, у меня, на самом деле, штатно стоит
> самосборанная libgtk+2, c .la-файлами, отличие только в способе передачи
> аргументов от libtool к gcc).

А в чём, собственно, это отличие?

> Если пользоваться pkgconfig, то все становится
> гораздо грустнее:
> 
> alex@pyro ~/tmp/libtool $ libtool --mode=link gcc -g -O -o test test.o
> `pkg-config --libs gtk+-2.0`
> gcc -g -O -o test test.o -Wl,--export-dynamic  -lgtk-x11-2.0
> -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0
> -lpango-1.0 /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so -ldl
> /usr/lib/libglib-2.0.so
> alex@pyro ~/tmp/libtool $ _
> 
> Видите? Все мучения с выкидыванием "лишних" .la файлов оказались тщетны.
> pkgconfig все равно вычислил всех, на кого так или иначе ссылается
> gtk-x11-2.0 и подсунул соответствующие параметры libtool'у.

$ grep ^Libs: /usr/lib/pkgconfig/gtk+-2.0.pc
Libs: -lgtk-${target}-2.0

$ strace -e trace=open pkg-config --libs gtk+-2.0
[...]
open("/usr/lib/pkgconfig", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) =
3
open("/usr/lib/pkgconfig/gtk+-2.0.pc", O_RDONLY) = 4
open("/usr/lib/pkgconfig/gdk-x11-2.0.pc", O_RDONLY) = 5
open("/usr/lib/pkgconfig/gdk-pixbuf-2.0.pc", O_RDONLY) = 6
open("/usr/lib/pkgconfig/gobject-2.0.pc", O_RDONLY) = 7
open("/usr/lib/pkgconfig/glib-2.0.pc", O_RDONLY) = 8
open("/usr/lib/pkgconfig/gmodule-2.0.pc", O_RDONLY) = 9
open("/usr/lib/pkgconfig/pangoxft.pc", O_RDONLY) = 10
open("/usr/lib/pkgconfig/pango.pc", O_RDONLY) = 11
open("/usr/lib/pkgconfig/pangox.pc", O_RDONLY) = 12
open("/usr/lib/pkgconfig/atk.pc", O_RDONLY) = 13
-Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0

Похоже, достаточно "просто" отучить "pkg-config --libs" от рекурсии,
или, ещё лучше, добавить pkg-config'у новый параметр,
включающий/выключающий эту рекурсию.

P.S. Не пора ли нам с этой темой в devel@?


-- 
ldv

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

Re: [sisyphus] Обнаружены новые враги народа! (was: Возвращаясь ...)

[Alexey Morozov]

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

On Tue, Dec 16, 2003 at 03:50:57PM +0300, Dmitry V. Levin wrote:
> On Tue, Dec 16, 2003 at 06:16:48PM +0600, Alexey Morozov wrote:
> > Он работает. Но работает не столько потому что Вы патчите libtool.m4, а
> > потому что Вы патчите ltmain.sh, не давая ему проскакать по списку
> > $dependency_libs (строка 2150 и ниже). А это, кстати, можно сделать, и не
> > трогая libtool.m4.
> У вас есть патч, который делает это лучше?  Так давайте его сюда.
Есть исправление. Подготовлю патч, отправлю лично. Видимо,
завтра-послезавтра.

> > P.S. Кстати, есть еще одна довольно-таки неприятная проблема: pkgconfig
> 
> Да, конечно.  Но
> 1. пользователей pkgconfig меньше;
Поставим вопрос ребром: rpm и BDB в их число не входят? :-)

> 2. нельзя объять необъятное;
Это точно :-). Можно сломать необъятное :-).

> 3. до исправления pkgconfig очередь тоже дойдёт. :)
Предупредите заранее, пожалуйста. Я сохраню бэкапы :-).

> > самосборанная libgtk+2, c .la-файлами, отличие только в способе передачи
> > аргументов от libtool к gcc).
> А в чём, собственно, это отличие?
-lsome vs /path/to/lib/libsome.so.

Обратите внимание на отличие между способом линковки всяких atk
(которые из сизифа, без .la) и glib (который самособранный, с .la):

> > alex@pyro ~/tmp/libtool $ libtool --mode=link gcc -g -O -o test test.o
> > `pkg-config --libs gtk+-2.0`
> > gcc -g -O -o test test.o -Wl,--export-dynamic  -lgtk-x11-2.0
> > -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0
> > -lpango-1.0 /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so -ldl
> > /usr/lib/libglib-2.0.so
> > alex@pyro ~/tmp/libtool $ _


> $ grep ^Libs: /usr/lib/pkgconfig/gtk+-2.0.pc
> Libs: -lgtk-${target}-2.0
На это я уже поглядел.

А вот до strace руки не дошли.
> $ strace -e trace=open pkg-config --libs gtk+-2.0
> [...]
> open("/usr/lib/pkgconfig", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) =
> 3
> open("/usr/lib/pkgconfig/gtk+-2.0.pc", O_RDONLY) = 4
...

> Похоже, достаточно "просто" отучить "pkg-config --libs" от рекурсии,
> или, ещё лучше, добавить pkg-config'у новый параметр,
> включающий/выключающий эту рекурсию.
Да, вероятно, это решит проблему.

> P.S. Не пора ли нам с этой темой в devel@?
Видимо, пора. Сейчас, переподпишусь только. Только, видимо, для меня
сейчас все эти разборки с пакетизацией линукса - скорее побочная
деятельность, постольку поскольку она нужна для собственных задач.
Поэтому особенно активного участия не ожидайте.

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

Re: [sisyphus] Обнаружены новые враги народа! (was: Возвращаясь ...)

[Dmitry V. Levin]

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

On Tue, Dec 16, 2003 at 07:23:52PM +0600, Alexey Morozov wrote:
> On Tue, Dec 16, 2003 at 03:50:57PM +0300, Dmitry V. Levin wrote:
> > On Tue, Dec 16, 2003 at 06:16:48PM +0600, Alexey Morozov wrote:
> > > Он работает. Но работает не столько потому что Вы патчите libtool.m4, а
> > > потому что Вы патчите ltmain.sh, не давая ему проскакать по списку
> > > $dependency_libs (строка 2150 и ниже). А это, кстати, можно сделать, и не
> > > трогая libtool.m4.
> > У вас есть патч, который делает это лучше?  Так давайте его сюда.
> Есть исправление. Подготовлю патч, отправлю лично. Видимо,
> завтра-послезавтра.

Ok

> > > P.S. Кстати, есть еще одна довольно-таки неприятная проблема: pkgconfig
> > 
> > Да, конечно.  Но
> > 1. пользователей pkgconfig меньше;
> Поставим вопрос ребром: rpm и BDB в их число не входят? :-)

Наверняка не входят. :)

> > 2. нельзя объять необъятное;
> Это точно :-). Можно сломать необъятное :-).
> 
> > 3. до исправления pkgconfig очередь тоже дойдёт. :)
> Предупредите заранее, пожалуйста. Я сохраню бэкапы :-).
> 
> > > самосборанная libgtk+2, c .la-файлами, отличие только в способе передачи
> > > аргументов от libtool к gcc).
> > А в чём, собственно, это отличие?
> -lsome vs /path/to/lib/libsome.so.

А кто этот /path/to/lib/libsome.so делает?

> Обратите внимание на отличие между способом линковки всяких atk
> (которые из сизифа, без .la) и glib (который самособранный, с .la):

В чём же оно?

> > Похоже, достаточно "просто" отучить "pkg-config --libs" от рекурсии,
> > или, ещё лучше, добавить pkg-config'у новый параметр,
> > включающий/выключающий эту рекурсию.
> Да, вероятно, это решит проблему.
> 
> > P.S. Не пора ли нам с этой темой в devel@?
> Видимо, пора. Сейчас, переподпишусь только. Только, видимо, для меня
> сейчас все эти разборки с пакетизацией линукса - скорее побочная
> деятельность, постольку поскольку она нужна для собственных задач.
> Поэтому особенно активного участия не ожидайте.

Ok


-- 
ldv

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

Re: [sisyphus] Обнаружены новые враги народа! (was: Возвращаясь ...)

[Alexey Morozov]

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

On Tue, Dec 16, 2003 at 04:40:48PM +0300, Dmitry V. Levin wrote:
> > Есть исправление. Подготовлю патч, отправлю лично. Видимо,
> > завтра-послезавтра.
> Ok

> > > А в чём, собственно, это отличие?
> > -lsome vs /path/to/lib/libsome.so.
> А кто этот /path/to/lib/libsome.so делает?
См. ниже

> > Обратите внимание на отличие между способом линковки всяких atk
> > (которые из сизифа, без .la) и glib (который самособранный, с .la):
> В чём же оно?
В том, что если libtool не находит подходящего к -lsome .la файла (то
есть, libsome.la) в путях для линковки, то она так и передает соотв.
параметр gcc/линкеру: -lsome

А если находит - выцепляет из него library_names и подставляет вместо
-lsome полный путь: /path/to/lib/libsome.so (в принципе, возможны
варианты). Ну, и тот пример это наглядно демонстрировал.

В общем, на общеупотребимой функциональности это никак не сказывается,
насколько я понимаю.


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

[sisyphus] Re: Обнаружены новые враги народа! (was: Возвращаясь ...)

[Michael Shigorin]

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

On Tue, Dec 16, 2003 at 07:23:52PM +0600, Alexey Morozov wrote:
> Только, видимо, для меня сейчас все эти разборки с пакетизацией
> линукса - скорее побочная деятельность, постольку поскольку она
> нужна для собственных задач.  Поэтому особенно активного
> участия не ожидайте.

Алексей, сами же сдаете способ расшевелить Вас! ;-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [sisyphus] Обнаружены новые враги народа! (was: Возвращаясь ...)

[Serge Pavlovsky]

В ?? 16.12.2003, в 14:50, Dmitry V. Levin пишет:
> Похоже, достаточно "просто" отучить "pkg-config --libs" от рекурсии,
> или, ещё лучше, добавить pkg-config'у новый параметр,
> включающий/выключающий эту рекурсию.

еще придется научить все пакеты передавать его только при отсутствии
-static ;)
-- 
Serge Pavlovsky <pal@interexc.com>

Re: [sisyphus] Обнаружены новые враги народа! (was: Возвращаясь ...)

[Alexey Morozov]

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

On Tue, Dec 16, 2003 at 04:27:52PM +0200, Serge Pavlovsky wrote:
> В ?? 16.12.2003, в 14:50, Dmitry V. Levin пишет:
> > Похоже, достаточно "просто" отучить "pkg-config --libs" от рекурсии,
> > или, ещё лучше, добавить pkg-config'у новый параметр,
> > включающий/выключающий эту рекурсию.
> еще придется научить все пакеты передавать его только при отсутствии
> -static ;)
Не нужно :-).
Нужно все пакеты обучить libtool'у и вернуть взад .la файлы :-).

На самом деле, я думаю, количество тех, кто пользуется pkgconfig и
НЕ пользуется autotools довольно незначительно (если вообще не пустое
множество). Так что, надежда на счастье есть :-)


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

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

[Serge Pavlovsky]

В ??, 11.12.2003, в 16:30, Dmitry V. Levin пишет:
> За что вы так любите статические библиотеки? :)

а чего их не любить ? работают бытрее, отлаживать проще ...
-- 
Serge Pavlovsky <pal@interexc.com>

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

[Alexey Tourbin]

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

On Fri, Dec 12, 2003 at 04:57:04PM +0200, Serge Pavlovsky wrote:
> В ??, 11.12.2003, в 16:30, Dmitry V. Levin пишет:
> > За что вы так любите статические библиотеки? :)
> 
> а чего их не любить ? работают бытрее, отлаживать проще ...

Работают быстрее только в идеальных условиях.
Отлаживать так же, это зависит от стрипнутости.

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

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

[Serge Pavlovsky]

В ?? 12.12.2003, в 17:38, Alexey Tourbin пишет:
> On Fri, Dec 12, 2003 at 04:57:04PM +0200, Serge Pavlovsky wrote:
> > В ??, 11.12.2003, в 16:30, Dmitry V. Levin пишет:
> > > За что вы так любите статические библиотеки? :)
> > 
> > а чего их не любить ? работают бытрее, отлаживать проще ...
> 
> Работают быстрее только в идеальных условиях.
> Отлаживать так же, это зависит от стрипнутости.

то-то у меня пока 
b main
r
не сделаешь, не видно вообще ничего из so

-- 
Serge Pavlovsky <pal@interexc.com>

Re: [sisyphus][JT] напечатаннонапечатаннонапечатанному

[Andrey Rahmatullin]

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

А что это с темой? Уже 3-я копия "напечатанно" пошла.
-- 
> В частности, TCB реализован в России и Польше.
Я бы сказал, что в Польше и России :)
		-- ldv in community@

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

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

[Michael Shigorin]

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

On Thu, Dec 11, 2003 at 05:30:42PM +0300, Dmitry V. Levin wrote:
> За что вы так любите статические библиотеки? :)

Бывает нужно.  И убивать функциональность такими пластами --
значит, решать за ее пользователей.  Причем они таковыми могут
оказаться неожиданно для себя.

:(

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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