[devel] Патч на libtool про link_all_deplibs

[devel] Патч на libtool про link_all_deplibs

[Alexey Morozov]

[-- Attachment #1.1: Type: text/plain, Size: 1451 bytes --]

В аттачменте патчик, который позволяет выставлять (на платформе
*-*-linux*) правильное значение для link_all_deplibs (то есть, no),
даже если используются неправленные AC-макросы для libtool.

Это, позволяет, в частности, обойтись только libtoolize --copy --force,
без aclocal. Пока опробовано только на ImageMagick. Работает :-))

Должен использоваться ВМЕСТЕ с libtool-1.5-alt-link_all_deplibs.patch,
предположительно, последним, 29ым патчем в libtool_1.5-1.5-alt10.

Я провел небольшие тесты, дополнительно к тем, с которыми идет libtool.
Все работает, как и требуется (то есть, gcc на этапе линковке передаются
только те библиотеки, которые реально нужны). И для статической,
и для динамической линковки (см. н-р, depdemo/ в дистрибуции libtool).

Так что, .la-файлы можно заковыривать обратно, никому они сильно мешать
уже не должны (а k3b, н-р, снова заработает, и остальные, которым
_действительно_ нужна функциональность libltdl)

Мой патчик, конечно, выглядит, скорее, хаком, а вот
libtool-1.5-alt-link_all_deplibs.patch by ldv, как мне кажется, вполне
реально пропихнуть в upstream. Сегодня попробую написать этому Scott
James Remnant, надеюсь, "все будет хорошо".

P.S. Очень хочу взад статические библиотеки, по крайней мере,
libz/glib2/gtk+2/libxml2/libexpat. Либо (меньше, конечно) хочу механизм
автоматической пересборки RPM'ов с включенными статическими переменными.
Н-р, через определяемую глобально в каком-нибудь rpmrc переменную.


[-- Attachment #1.2: libtool-1.5-alt-link_all_deplibs-runtime.patch --]
[-- Type: text/plain, Size: 457 bytes --]

diff -urN libtool-1.5.orig/ltmain.sh libtool-1.5/ltmain.sh
--- libtool-1.5.orig/ltmain.sh	2003-04-15 05:34:17 +0700
+++ libtool-1.5/ltmain.sh	2004-01-06 06:17:02 +0600
@@ -830,6 +830,11 @@
       # that all symbols are satisfied, otherwise we get a static library.
       allow_undefined=yes
       ;;
+    *-*-linux*)
+      if test "$link_all_deplibs" = unknown; then
+	link_all_deplibs=no
+      fi
+      ;;
     *)
       allow_undefined=yes
       ;;

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

Re: [devel] Патч на libtool про link_all_deplibs

[Lokhin]

6 Январь 2004 13:27, Alexey Morozov написал:
> Так что, .la-файлы можно заковыривать обратно, никому они сильно мешать
> уже не должны (а k3b, н-р, снова заработает, и остальные, которым
> _действительно_ нужна функциональность libltdl)

Не сработало. Собирал "руками", не rpm. Да и k3b для плагинов ltdl, вроде, не нужна.
Грешу на kdelibs...

Re: [devel] Патч на libtool про link_all_deplibs

[Sergey V Turchin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 546 bytes --]

В сообщении от 6 Январь 2004 14:54 Lokhin написал(a):
> 6 Январь 2004 13:27, Alexey Morozov написал:
> > Так что, .la-файлы можно заковыривать обратно, никому они
> > сильно мешать уже не должны (а k3b, н-р, снова заработает, и
> > остальные, которым _действительно_ нужна функциональность
> > libltdl)
>
> Не сработало. Собирал "руками", не rpm. Да и k3b для плагинов
> ltdl, вроде, не нужна. Грешу на kdelibs...
Зря :-)

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] Патч на libtool про link_all_deplibs

[Dmitry V. Levin]

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

On Tue, Jan 06, 2004 at 04:27:57PM +0600, Alexey Morozov wrote:
> В аттачменте патчик, который позволяет выставлять (на платформе
> *-*-linux*) правильное значение для link_all_deplibs (то есть, no),
> даже если используются неправленные AC-макросы для libtool.
> 
> Это, позволяет, в частности, обойтись только libtoolize --copy --force,
> без aclocal. Пока опробовано только на ImageMagick. Работает :-))

Спасибо, я попробую.

> P.S. Очень хочу взад статические библиотеки, по крайней мере,
> libz/glib2/gtk+2/libxml2/libexpat. Либо (меньше, конечно) хочу механизм
> автоматической пересборки RPM'ов с включенными статическими переменными.
> Н-р, через определяемую глобально в каком-нибудь rpmrc переменную.

Статический zlib я убирать не планирую.
Что касается библиотек, использующих Xlib, то я против.
Всё остальное - исходя из здравого смысла.

Пересобрать со статикой любой пакет, в котором сборку статики выключили
по-умолчанию, можно путём "rpmbuild --rebuild --enable static".


-- 
ldv

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

Re: [devel] Патч на libtool про link_all_deplibs

[Alexey Morozov]

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

On Tue, Jan 06, 2004 at 04:02:36PM +0300, Dmitry V. Levin wrote:
> On Tue, Jan 06, 2004 at 04:27:57PM +0600, Alexey Morozov wrote:
> > Это, позволяет, в частности, обойтись только libtoolize --copy --force,
> > без aclocal. Пока опробовано только на ImageMagick. Работает :-))
> Спасибо, я попробую.
Угу.

> > P.S. Очень хочу взад статические библиотеки, по крайней мере,
> > libz/glib2/gtk+2/libxml2/libexpat. Либо (меньше, конечно) хочу механизм
> > автоматической пересборки RPM'ов с включенными статическими переменными.
> > Н-р, через определяемую глобально в каком-нибудь rpmrc переменную.
> Статический zlib я убирать не планирую.
И то хорошо.

> Что касается библиотек, использующих Xlib, то я против.
Почему?

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

> Пересобрать со статикой любой пакет, в котором сборку статики выключили
> по-умолчанию, можно путём "rpmbuild --rebuild --enable static".
Может, уже выработать механизм некоторых Make.defs'ов, или как они там в
портах назывались? Менять-то по сути, немного надо, просто договориться о
формате и порядке использования всяких общеупотребительных параметров, типа
with_static, with_kde, with_gnome итп. Кому надо, будут пользоваться, а то
сейчас - кто в лес, кто по дрова.


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

Re: [devel] Патч на libtool про link_all_deplibs

[Alexey Morozov]

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

On Tue, Jan 06, 2004 at 02:54:07PM +0300, Lokhin wrote:
> 6 Январь 2004 13:27, Alexey Morozov написал:
> > Так что, .la-файлы можно заковыривать обратно, никому они сильно мешать
> > уже не должны (а k3b, н-р, снова заработает, и остальные, которым
> > _действительно_ нужна функциональность libltdl)
> Не сработало. Собирал "руками", не rpm. Да и k3b для плагинов ltdl, вроде,
> не нужна.
> Грешу на kdelibs...
Она, скорее всего, поднимает плагины через какую-либо KDEшную обвязку,
которая, в свою очередь, дергает ltdl. В своем нынешнем виде (без .la файлов,
и не захаченная нездравым способом) libltdl в AltLinux не рабочая (то есть,
не отвечает собственной спецификации и докам). В общем:

- Наковыряйте мне килограмм изюма из ваших булочек.
...
- А у вас булочки свежие? Нет? Тогда заковыривайте изюм обратно.

На самом деле, я С ИНТЕРЕСОМ выслушаю ВСЕ претензии по поводу софта,
который собирался, но перестал после libtoolize --copy --force (без aclocal).
И попробую эти претензии разрешить.


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

Re: [devel] Патч на libtool про link_all_deplibs

[Dmitry V. Levin]

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

On Tue, Jan 06, 2004 at 07:48:39PM +0600, Alexey Morozov wrote:
[...]
> > > P.S. Очень хочу взад статические библиотеки, по крайней мере,
> > > libz/glib2/gtk+2/libxml2/libexpat. Либо (меньше, конечно) хочу механизм
> > > автоматической пересборки RPM'ов с включенными статическими переменными.
> > > Н-р, через определяемую глобально в каком-нибудь rpmrc переменную.
> > Статический zlib я убирать не планирую.
> И то хорошо.
> 
> > Что касается библиотек, использующих Xlib, то я против.
> Почему?

Здравый смысл не позволяет. :)

> > Всё остальное - исходя из здравого смысла.
> Тогда я хочу услышать соображения этого "здравого смысла".

Есть простой критерий: если в Сизифе используется, то надо собирать.
Например, zlib-devel-static используется для сборки rpm,
libreadline-devel-static используется для сборки sash, и т.п.

> > Пересобрать со статикой любой пакет, в котором сборку статики выключили
> > по-умолчанию, можно путём "rpmbuild --rebuild --enable static".
> Может, уже выработать механизм некоторых Make.defs'ов, или как они там в
> портах назывались? Менять-то по сути, немного надо, просто договориться о
> формате и порядке использования всяких общеупотребительных параметров, типа
> with_static, with_kde, with_gnome итп. Кому надо, будут пользоваться, а то
> сейчас - кто в лес, кто по дрова.

Я не против.


-- 
ldv

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

[devel] Re: Патч на libtool про link_all_deplibs

[Michael Shigorin]

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

On Tue, Jan 06, 2004 at 07:48:39PM +0600, Alexey Morozov wrote:
> > Пересобрать со статикой любой пакет, в котором сборку статики
> > выключили по-умолчанию, можно путём "rpmbuild --rebuild
> > --enable static".
> Может, уже выработать механизм некоторых Make.defs'ов, или как
> они там в портах назывались? Менять-то по сути, немного надо,
> просто договориться о формате и порядке использования всяких
> общеупотребительных параметров, типа with_static, with_kde,
> with_gnome итп. Кому надо, будут пользоваться, а то сейчас -
> кто в лес, кто по дрова.

Эт да.  Сгоряча оставил кучку своих lib* безусловно без статиков,
правда, оно вряд ли кому там действительно понадобится.

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

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

Re: [devel] Re: Патч на libtool про link_all_deplibs

[Vitaly Lipatov]

On 6 Январь 2004 23:04, Michael Shigorin wrote:

> Эт да.  Сгоряча оставил кучку своих lib* безусловно без
> статиков, правда, оно вряд ли кому там действительно
> понадобится.
Я обычно оставляю "статики", но если их сборка почему-то 
ломается, я о них совсем не сожалею :)

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] Патч на libtool про link_all_deplibs

[Alexey Morozov]

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

On Tue, Jan 06, 2004 at 09:53:19PM +0300, Dmitry V. Levin wrote:
> > > Всё остальное - исходя из здравого смысла.
> > Тогда я хочу услышать соображения этого "здравого смысла".
> Есть простой критерий: если в Сизифе используется, то надо собирать.
> Например, zlib-devel-static используется для сборки rpm,
> libreadline-devel-static используется для сборки sash, и т.п.
Ну, сомнительный критерий. Сомнительный в силу своей необязательности.

К тому же, довольно сильно бьющий по ISV и прочим. Не все же кастомными
проектами заниматься. А если делать что-либо "продуктовое", и при этом не
ставить "Minimal System Requirements: ALT Linux Sisyphus-20040107", то
довольно неприятно получается. Я, конечно, понимаю, проблемы индейцев вождя не
...., но тем не менее.

А в чем минусы-то наличия статических библиотек?

> > формате и порядке использования всяких общеупотребительных параметров, типа
> > with_static, with_kde, with_gnome итп. Кому надо, будут пользоваться, а то
> > сейчас - кто в лес, кто по дрова.
> Я не против.
Ладно, я для себя попробую сделать, если что получится здравое - расскажу.


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

[devel] .a vs .so (was Re: Патч на libtool про link_all_deplibs)

[Mikhail Zabaluev]

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

Hello Alexey,

On Wed, Jan 07, 2004 at 02:12:25AM +0600, Alexey Morozov wrote:
>
> > Есть простой критерий: если в Сизифе используется, то надо собирать.
> > Например, zlib-devel-static используется для сборки rpm,
> > libreadline-devel-static используется для сборки sash, и т.п.
> Ну, сомнительный критерий. Сомнительный в силу своей необязательности.
> 
> К тому же, довольно сильно бьющий по ISV и прочим. Не все же кастомными
> проектами заниматься. А если делать что-либо "продуктовое", и при этом не
> ставить "Minimal System Requirements: ALT Linux Sisyphus-20040107", то
> довольно неприятно получается. Я, конечно, понимаю, проблемы индейцев вождя не
> ...., но тем не менее.
> 
> А в чем минусы-то наличия статических библиотек?

Большинство из них никогда, никому и нигде не нужны.
Особенно это касается "десктопных" библиотек.
Если они кому-то понадобились, это означает, что кто-то не всё
понял о разделяемых библиотеках. Или о правильных build tools.
Более того, статические библиотеки могут быть контрпродуктивны.
Вспомните историю с багом в zlib.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
"His eyes were cold.  As cold as the bitter winter snow that was falling
outside.  Yes, cold and therefore difficult to chew..."

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

Re: [devel] .a vs .so (was Re: ðÁÔÞ ÎÁ libtool ÐÒÏ link_all_deplibs)

[Alexey Lubimov]

Mikhail Zabaluev wrote:
>>А в чем минусы-то наличия статических библиотек?
> 
> 
> Большинство из них никогда, никому и нигде не нужны.
> Особенно это касается "десктопных" библиотек.
> Если они кому-то понадобились, это означает, что кто-то не всё
> понял о разделяемых библиотеках. Или о правильных build tools.
> Более того, статические библиотеки могут быть контрпродуктивны.
> Вспомните историю с багом в zlib.

Это все замечательно, но

1) дистрибутив не должен ориентироваться только на самого себя, бездумно 
ломая совместимость со всеми остальными программами даже по исходникам.
2)Даже одна такая программа, буде она важна для пользователя, является 
достаточным поводом для смены дистра (если много библиотек пересобирать 
придется да и поддерживать потом замучаешься).
3)глупо использовать альт на 7 компьютерах (прокатило) и допустим дебиан 
(альт уже не прокатил) на 3 только из за отсутствия в альте статических 
либ. На всех десяти будет стоять дебиан, потому что он демократичнее.
Дебиан только пример.
4)статически либы _нужны_ там, где они нужны. В программах, которые не 
должны зависеть от общих библиотек и их версий. И такие программы иногда 
надо собирать. Отрезание этих программ убивает дистр похлеще многих 
других возможных недостатков.

Нет желания выделять -static, кладите la в -devel. Нельзя вот так серпом 
  по либам...

Re: [devel] .a vs .so (was Re: ðÁÔÞ ÎÁ libtool ÐÒÏ link_all_deplibs)

[Igor Tertishny]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2937 bytes --]

> 1) дистрибутив не должен ориентироваться только на самого себя, бездумно
> ломая совместимость со всеми остальными программами даже по исходникам.

Поностью согласен. Мы "впереди планеты всей" и посылаем весь мир по известному 
адресу. Вот только мы останемся на месте с этим своим "впереди", а мир пойдет 
дальше и пользователи вместе с ним. Почему? Да потому что альтом становится 
невозможно пользоваться и собрать в нем что-либо редкое, что легко собирается 
в любом другом дистре (проверено лично на трех дистрибутивах). Альтом стало 
невозможно пользоваться и для разработки приложений. Чтобы у меня не стояла 
работа над прогой, мне пришлось Slackware ставить - в альте kdevelop попросту 
ничего не компилит из-за никому не нужных шаманских вытанцовываний с *.la. 
Возникает вопрос - зачем это все нужно? Не для удовлетворения ли амбиций 
одного человека?
 
> 2)Даже одна такая программа, буде она важна для пользователя, является
> достаточным поводом для смены дистра (если много библиотек пересобирать
> придется да и поддерживать потом замучаешься).

Что мне и пришлось, в конце концов, сделать - работа-то стоит из-за всех этих 
извращений. А обидно-то как... Сколько лет и сколько сил альту отдано... 
Постоянно перегружаюсь обратно в Сизиф, обновляюсь и все пытаюсь сделать хоть 
что-то мне нужное. Увы...

> 4)статически либы _нужны_ там, где они нужны. В программах, которые не
> должны зависеть от общих библиотек и их версий. И такие программы иногда
> надо собирать. Отрезание этих программ убивает дистр похлеще многих
> других возможных недостатков.

Именно убивает. Напрочь убивает. Странно все это, господа... Очень странно.

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

Re: [devel] Re: Патч на libtool про link_all_deplibs

[Igor Tertishny]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1006 bytes --]

> Эт да.  Сгоряча оставил кучку своих lib* безусловно без статиков,
> правда, оно вряд ли кому там действительно понадобится.

Я на всякий случай пошел по простейшему пути if - else, не убирая окончательно 
упоминания о статике из спеков. Вдруг, возвращаться придется. Не знаю 
правильная ли, но схема ниже. Может, кто подскажет лучшую. Да и вообще, раз 
уж отказались от статики, то хотелось бы иметь механизм, при котором при 
сборке статической проги она автоматом бы потянула за собой пересборку в 
статике всех тех, кто ей нужет, но отстутствует в дистре. Наверное, хочу 
невозможного... Но все время думаю над таким механизмом - пересобирать каждую 
либу сильно напряжно. Надеюсь, чего и удастся надумать.

%define static 0
...

%if %static
%configure \
    ... \
    --enable-static
%else
%configure \
    ... \
    --disable-static
%endif
...

%if %static
%files -n lib%name-devel-static
%_libdir/%name/*.a
...
%endif

Примерно так. Не лучший способ, понятно. Подскажите, что смотреть для лучшего.

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

Re: [devel] .a vs .so (was Re: Патч на libtool про link_all_deplibs)

[Alexey Morozov]

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

On Wed, Jan 07, 2004 at 07:31:56PM +0300, Mikhail Zabaluev wrote:
> > А в чем минусы-то наличия статических библиотек?
> 
> Большинство из них никогда, никому и нигде не нужны.
> Особенно это касается "десктопных" библиотек.
> Если они кому-то понадобились, это означает, что кто-то не всё
> понял о разделяемых библиотеках. Или о правильных build tools.
У кого-то, как я уже говорил, жизнь не такая замечательная, как
хотелось бы. Я ж уже рассказывал, как ловко сломался TAO, когда
админы взяли и накатили апдейты на восьмой редхат
(glibc-2.2.92x -> glibc-2.3.x). То есть, все как настоящее, поднимается,
работает, только запросы диспатчиться перестали. То-то было весело,
то-то хорошо. Еще одна бессонная ночь на работе.
Хорошо еще, что тот проект был _сугубо_ кастомным и _сугубо_ ограниченным,
а если бы понадобилось такой апдейт хотя бы на десяток разных инсталляций
накатить?

И это я еще не говорю о том, что этих чертовых линуксов на самом деле -
хоть пруд пруди. Можно сделать пятьдесят билдов, и все равно останется
кто-то, кто начнет гундеть: а вот под мой любимый SuperCoolLinux у вас
нет сборки.

> Более того, статические библиотеки могут быть контрпродуктивны.
> Вспомните историю с багом в zlib.
Могут. Но мне проще читать багтрек, чем в десять вечера начинать
понимать, что и где там сломалось в очередной раз, от того, что
кто-то не думая, чего-то поменял в системе.


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

[devel] Re: .a vs .so (was Re: ???????? ???? libtool ?????? link_all_deplibs)

[Alexey Tourbin]

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

On Wed, Jan 07, 2004 at 08:58:11PM +0300, Alexey Lubimov wrote:
> 4)статически либы _нужны_ там, где они нужны. В программах, которые не 
> должны зависеть от общих библиотек и их версий. И такие программы иногда 
> надо собирать. Отрезание этих программ убивает дистр похлеще многих 
> других возможных недостатков.

Необходимость статической линковки не обоснована.  "Не должны зависеть
от библиотек" -- "всё свое ношу с собой".  Независимость-то мнимая.

Если что-то нужно перенести в другую среду, в другой среде нужно сделать
каталог /usr/lib/ALT, сложить в него все либы и запускать

$ LD_LIBRARY_PATH=/usr/lib/ALT program_from_alt

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

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

[devel] Re: Патч на libtool про link_all_deplibs

[Alexey Tourbin]

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

On Thu, Jan 08, 2004 at 11:21:32AM +0200, Igor Tertishny wrote:
> %if %static
> %files -n lib%name-devel-static
> %_libdir/%name/*.a
> ...
> %endif
> 
> Примерно так. Не лучший способ, понятно. Подскажите, что смотреть для лучшего.

[devel] Re: QA SpamBot и *.la -- devel-static

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

Re: [devel] .a vs .so

[Dmitry V. Levin]

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

On Thu, Jan 08, 2004 at 10:53:32AM +0200, Igor Tertishny wrote:
> > 1) дистрибутив не должен ориентироваться только на самого себя, бездумно
> > ломая совместимость со всеми остальными программами даже по исходникам.
> 
> Поностью согласен. Мы "впереди планеты всей" и посылаем весь мир по известному 
> адресу. Вот только мы останемся на месте с этим своим "впереди", а мир пойдет 
> дальше и пользователи вместе с ним. Почему? Да потому что альтом становится 
> невозможно пользоваться и собрать в нем что-либо редкое, что легко собирается 
> в любом другом дистре (проверено лично на трех дистрибутивах). Альтом стало 
> невозможно пользоваться и для разработки приложений. Чтобы у меня не стояла 
> работа над прогой, мне пришлось Slackware ставить - в альте kdevelop попросту 
> ничего не компилит из-за никому не нужных шаманских вытанцовываний с *.la. 
> Возникает вопрос - зачем это все нужно? Не для удовлетворения ли амбиций 
> одного человека?
>  
> > 2)Даже одна такая программа, буде она важна для пользователя, является
> > достаточным поводом для смены дистра (если много библиотек пересобирать
> > придется да и поддерживать потом замучаешься).
> 
> Что мне и пришлось, в конце концов, сделать - работа-то стоит из-за всех этих 
> извращений. А обидно-то как... Сколько лет и сколько сил альту отдано... 
> Постоянно перегружаюсь обратно в Сизиф, обновляюсь и все пытаюсь сделать хоть 
> что-то мне нужное. Увы...
> 
> > 4)статически либы _нужны_ там, где они нужны. В программах, которые не
> > должны зависеть от общих библиотек и их версий. И такие программы иногда
> > надо собирать. Отрезание этих программ убивает дистр похлеще многих
> > других возможных недостатков.
> 
> Именно убивает. Напрочь убивает. Странно все это, господа... Очень странно.

Хватит ныть.

Если вы не в состоянии понять, зачем нужно то или иное изменение в Сизифе,
то это, конечно, плохо; попробуйте всё-таки сами понять, попробуйте
спросить у тех, кто уже понял.  И поскольку Сизиф раздулся за последнее
время до слабоподдерживаемых размеров, то наивно ожидать того, что
существенные изменения можно провести за день, неделю, даже месяц.
Если у вас не хватает терпения - уходите и не мешайте работать.


-- 
ldv

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

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

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 03:40:02PM +0300, Alexey Tourbin wrote:
> Необходимость статической линковки не обоснована.  "Не должны зависеть
> от библиотек" -- "всё свое ношу с собой".  Независимость-то мнимая.
> 
> Если что-то нужно перенести в другую среду, в другой среде нужно сделать
> каталог /usr/lib/ALT, сложить в него все либы и запускать
> 
> $ LD_LIBRARY_PATH=/usr/lib/ALT program_from_alt
Вы серьезно? Нет, таки правда, взять и потащить за собой половину альта?
Скажите честно, Вы так делали?

> Одним словом, для переноса в другие среды статическая линковка не нужна.
Хех. То-то, как кто-нибудь возьмется что-либо посложнее в бинарном виде
распространять, так и кладет статику, как last resort.


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

[devel] Re: .a vs .so

[Alexey Tourbin]

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

On Thu, Jan 08, 2004 at 08:19:47PM +0600, Alexey Morozov wrote:
> > Если что-то нужно перенести в другую среду, в другой среде нужно сделать
> > каталог /usr/lib/ALT, сложить в него все либы и запускать
> > 
> > $ LD_LIBRARY_PATH=/usr/lib/ALT program_from_alt
> Вы серьезно? Нет, таки правда, взять и потащить за собой половину альта?
> Скажите честно, Вы так делали?

Нет, не половину альта, а только те либы, которые иначе были бы
влинкованы статически.  Получается "то же на то же".  При числе программ
больше 1 получается выгода.

> > Одним словом, для переноса в другие среды статическая линковка не нужна.
> Хех. То-то, как кто-нибудь возьмется что-либо посложнее в бинарном виде
> распространять, так и кладет статику, как last resort.

"Last resort" -- "последнее прибежище негодяев". :)

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

[devel] Re: .a vs .so (was Re: ???????? ???? libtool ?????? link_all_deplibs)

[Michael Shigorin]

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

On Thu, Jan 08, 2004 at 03:40:02PM +0300, Alexey Tourbin wrote:
> Если что-то нужно перенести в другую среду, в другой среде
> нужно сделать каталог /usr/lib/ALT, сложить в него все либы и

Не уверен, что это приемлемо для ISV.

Между идеалами и партнерами я выбираю партнеров.  ALT -- ?

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

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

Re: [devel] .a vs .so

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 04:43:26PM +0300, Dmitry V. Levin wrote:
> > Именно убивает. Напрочь убивает. Странно все это, господа... Очень странно.
> Хватит ныть.
> 
> Если вы не в состоянии понять, зачем нужно то или иное изменение в Сизифе,
> то это, конечно, плохо; попробуйте всё-таки сами понять, попробуйте
> спросить у тех, кто уже понял.  И поскольку Сизиф раздулся за последнее
> время до слабоподдерживаемых размеров, то наивно ожидать того, что
> существенные изменения можно провести за день, неделю, даже месяц.
> Если у вас не хватает терпения - уходите и не мешайте работать.
Дмитрий, Вы правда хотите, чтобы все, кто [был] несогласен с Вашими
решениями, шли искать счастья в другом месте? Вам, как человеку, не
первый день крутящемуся в вареве линукс/open source девелопмента, думаю,
не надо рассказывать, что позиция разработчиков, выдержанная в стиле:

"Я Д'Артаньян, а вы все презервативы" и
"- мама, я не люблю мою маленькую сестренку!
 - ешь, что дают!", -
 
контрпродуктивна прежде всего для всех участников процесса. И в первую
очередь, для самих разработчиков в частности. А проекты такие, по моему
опыту, просто тихо дохнут, несмотря на все свои технологические
преимущества.

Впрочем, ладно, пора уже гасить эмоции и разговаривать по существу.

Вы смотрели на присланный мною патч? Как Вам кажется, он способен решить
проблему с обязательным перестроением autotools'ового барахла, или надо
еще что-то дополнительно придумывать? И если способен, то не пора ли
объявить план перехода на _нормальную_ сборочную систему. Я не настаиваю
на том, чтобы все разом бросились "вертать все взад", но и нынешнее
положение вещей меня не устраивает. И, как видно, не только меня.


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

[devel] Re: .a vs .so

[Michael Shigorin]

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

On Thu, Jan 08, 2004 at 04:43:26PM +0300, Dmitry V. Levin wrote:
> Если вы не в состоянии понять, зачем нужно то или иное
> изменение в Сизифе, то это, конечно, плохо; попробуйте всё-таки
> сами понять, попробуйте спросить у тех, кто уже понял.

Такие есть? (по данному вопросу)

> И поскольку Сизиф раздулся за последнее время до
> слабоподдерживаемых размеров, то наивно ожидать того, что
> существенные изменения можно провести за день, неделю, даже
> месяц.

Интересно -- если бы Морозова напугали как следует заранее --
сподвигся бы он на ковыряние в libtool или нет?..

(насвистывая "don't carry the world upon your shoulders")

> Если у вас не хватает терпения - уходите и не мешайте работать.

2 raorn: SYN...

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

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

Re: [devel] Re: .a vs .so (was Re: ???????? ???? libtool ?????? link_all_deplibs)

[Алексей Любимов]

Alexey Tourbin пишет:

>On Wed, Jan 07, 2004 at 08:58:11PM +0300, Alexey Lubimov wrote:
>  
>
>>4)статически либы _нужны_ там, где они нужны. В программах, которые не 
>>должны зависеть от общих библиотек и их версий. И такие программы иногда 
>>надо собирать. Отрезание этих программ убивает дистр похлеще многих 
>>других возможных недостатков.
>>    
>>
>
>Необходимость статической линковки не обоснована.  "Не должны зависеть
>от библиотек" -- "всё свое ношу с собой".  Независимость-то мнимая.
>
>Если что-то нужно перенести в другую среду, в другой среде нужно сделать
>каталог /usr/lib/ALT, сложить в него все либы и запускать
>
>$ LD_LIBRARY_PATH=/usr/lib/ALT program_from_alt
>  
>

или еще жестче и ближе к статику - chrpath


>Одним словом, для переноса в другие среды статическая линковка не нужна.
>  
>
Вопрос не в том, как и куда переносить _свое_.
Вопрос в том, что приходится заморачиваться с _чужим_, от которого часто 
зависит уже свое.
Множество программ требуют наличия статических либ. Причем не всегда 
явно требует.
Тот же кде со своими закидонами с поиском либ через la. Меня уже 
задолбали вопросами, как компилить KDE проги _в альте_.
А k3b?  молча собралась и молча не работает.

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

Все не так плохо, конечно, но в каждой шутке есть доля шутки...

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

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 05:31:22PM +0300, Alexey Tourbin wrote:
> > Вы серьезно? Нет, таки правда, взять и потащить за собой половину альта?
> > Скажите честно, Вы так делали?
> Нет, не половину альта, а только те либы, которые иначе были бы
> влинкованы статически.  Получается "то же на то же".  При числе программ
> больше 1 получается выгода.
Выгоды не получается. На практике возникают всякие неприятные моменты,
связанные с дистрибуцией и инсталляцией. К тому же, таскать приходится все,
начиная с libc. Что, в общем, крутовато для какой-нибудь приблудки,
ставящейся на левый веб-хостинг.

> > > Одним словом, для переноса в другие среды статическая линковка не нужна.
> > Хех. То-то, как кто-нибудь возьмется что-либо посложнее в бинарном виде
> > распространять, так и кладет статику, как last resort.
> "Last resort" -- "последнее прибежище негодяев". :)
Знаете, шутки шутками, а последние веяния с freedesktop.org, о которых
мне рассказывал дружок, показывает, что приходит осознание того, что до
dll/binary hell в юниксе уже недалеко, причем, методы решения проблем -
все такие же убогие (как в винде). Впрочем, это уже тема для отдельного
трепа, и никак не в рамках devel@.


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

Re: [devel] Патч на libtool про link_all_deplibs

[Sergey V Turchin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1478 bytes --]

В сообщении от 6 Январь 2004 16:54 Alexey Morozov написал(a):
> On Tue, Jan 06, 2004 at 02:54:07PM +0300, Lokhin wrote:
> > 6 Январь 2004 13:27, Alexey Morozov написал:
> > > Так что, .la-файлы можно заковыривать обратно, никому они
> > > сильно мешать уже не должны (а k3b, н-р, снова заработает, и
> > > остальные, которым _действительно_ нужна функциональность
> > > libltdl)
> >
> > Не сработало. Собирал "руками", не rpm. Да и k3b для плагинов
> > ltdl, вроде, не нужна.
> > Грешу на kdelibs...
>
> Она, скорее всего, поднимает плагины через какую-либо KDEшную
> обвязку, которая, в свою очередь, дергает ltdl
Да, в нынешнем виде там в имени файла s/\.la$/.so/ делается только.

> . В своем нынешнем
> виде (без .la файлов, и не захаченная нездравым способом) libltdl
> в AltLinux
Я собираю с %undefine __libtoolize, с libtool из исходных тарболов.
Патчи для замены lt_dlopen на dlopen не прикладываю,
т.к. не выявил разницы в работоспособности.

>  не рабочая (то есть, не отвечает собственной
> спецификации и докам). В общем:
>
> - Наковыряйте мне килограмм изюма из ваших булочек.
> ...
> - А у вас булочки свежие? Нет? Тогда заковыривайте изюм обратно.
>
> На самом деле, я С ИНТЕРЕСОМ выслушаю ВСЕ претензии по поводу
> софта, который собирался, но перестал после libtoolize --copy
> --force (без aclocal). И попробую эти претензии разрешить.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

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

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 04:38:05PM +0200, Michael Shigorin wrote:
> On Thu, Jan 08, 2004 at 04:43:26PM +0300, Dmitry V. Levin wrote:
> > Если вы не в состоянии понять, зачем нужно то или иное
> > изменение в Сизифе, то это, конечно, плохо; попробуйте всё-таки
> > сами понять, попробуйте спросить у тех, кто уже понял.
> Такие есть? (по данному вопросу)
Есть. Я. Именно поэтому я попытался придумать решение, при котором
Дмитрий сможет собирать rpm, не думая о том, какие libdb-devel у него
в данный момент стоят :-P. Проблема действительно есть, но то, как
её пытаются решить _все_, не только альт, меня совершенно не устраивает.
Хотя бы потому, что мне не все равно, как будет собираться моё
собственное поделие :-).

> > И поскольку Сизиф раздулся за последнее время до
> > слабоподдерживаемых размеров, то наивно ожидать того, что
> > существенные изменения можно провести за день, неделю, даже
> > месяц.
> Интересно -- если бы Морозова напугали как следует заранее --
> сподвигся бы он на ковыряние в libtool или нет?..
В данном случае, да. изничтожение .la - это повальная мода.
Хотя в остальных местах, как мне показалось, это был более итеративный
процесс, on case by case basis. Впрочем, хорошо там, где нас нет.

И к тому же, я просто ору громче всех. Основной патч писал таки Дмитрий
:-).


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

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

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 04:34:54PM +0200, Michael Shigorin wrote:
> On Thu, Jan 08, 2004 at 03:40:02PM +0300, Alexey Tourbin wrote:
> > Если что-то нужно перенести в другую среду, в другой среде
> > нужно сделать каталог /usr/lib/ALT, сложить в него все либы и
> Не уверен, что это приемлемо для ISV.
Это неприемлемо, если речь идет о вебхостингах. Там, во-первых, с
пространством и остальными ресурсами очень туго, а во-вторых,
с подозрением относятся к любому нескриптовому поделию. Тащить
libc просто потому что я знаю, что о бинарной бэквард-совместимости
в линуксе можно только мечтать - непозволительная роскошь.
И дело, кстати, не столько в проблемах "проклятых проприетарщиков",
сколько в специфике работы, даже ваша софтина - сплошь перловые скрипты.
Впрочем, это всё - злостный оффтопик, и с этим пора заканчивать.


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

Re: [devel] .a vs .so (was Re: Патч на libtool про link_all_deplibs)

[Dmitry V. Levin]

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

On Thu, Jan 08, 2004 at 03:59:03PM +0600, Alexey Morozov wrote:
[...]
> > Более того, статические библиотеки могут быть контрпродуктивны.
> > Вспомните историю с багом в zlib.
> Могут. Но мне проще читать багтрек [...]

Это вам легче.

А вот мне тогда и недели (или двух - не помню точно) форы не хватило,
чтобы отыскать все кривые пакеты, которые носят с собой модифицированные
версии zlib'а неизвестно какой версии.

Но это уже совсем другая история.


-- 
ldv

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

Re: [devel] Патч на libtool про link_all_deplibs

[Dmitry V. Levin]

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

On Tue, Jan 06, 2004 at 04:27:57PM +0600, Alexey Morozov wrote:
> Так что, .la-файлы можно заковыривать обратно, никому они сильно мешать
> уже не должны (а k3b, н-р, снова заработает, и остальные, которым
> _действительно_ нужна функциональность libltdl)

Кстати говоря, ещё один аргумент против .la-файлов - это избыточность.
Их на самом деле можно восстановить прямо по разделяемым библиотекам.


-- 
ldv

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

Re: [devel] Патч на libtool про link_all_deplibs

[Dmitry V. Levin]

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

On Tue, Jan 06, 2004 at 07:54:53PM +0600, Alexey Morozov wrote:
> On Tue, Jan 06, 2004 at 02:54:07PM +0300, Lokhin wrote:
> > 6 Январь 2004 13:27, Alexey Morozov написал:
> > > Так что, .la-файлы можно заковыривать обратно, никому они сильно мешать
> > > уже не должны (а k3b, н-р, снова заработает, и остальные, которым
> > > _действительно_ нужна функциональность libltdl)
> > Не сработало. Собирал "руками", не rpm. Да и k3b для плагинов ltdl, вроде,
> > не нужна.
> > Грешу на kdelibs...
> Она, скорее всего, поднимает плагины через какую-либо KDEшную обвязку,
> которая, в свою очередь, дергает ltdl. В своем нынешнем виде (без .la файлов,
> и не захаченная нездравым способом) libltdl в AltLinux не рабочая (то есть,
> не отвечает собственной спецификации и докам). В общем:

Напомните мне, что именно в этом ltdl ломается при отсутствии .la-файлов?


-- 
ldv

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

[devel] Re: Патч на libtool про link_all_deplibs

[Michael Shigorin]

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

On Thu, Jan 08, 2004 at 06:06:44PM +0300, Dmitry V. Levin wrote:
> > Так что, .la-файлы можно заковыривать обратно, никому они
> > сильно мешать уже не должны (а k3b, н-р, снова заработает, и
> > остальные, которым _действительно_ нужна функциональность
> > libltdl)
> Кстати говоря, ещё один аргумент против .la-файлов - это
> избыточность.  Их на самом деле можно восстановить прямо по
> разделяемым библиотекам.

По такой статье бОльшую часть сизифа можно просто убить.

Заодно стоит подумать о том, что configure (они немаленькие!) --
тоже избыточная информация, которую можно восстановить из куда
более компактной. (просьба не воспринимать как призыв к действию)

Решая проблемы, следует постараться не создать еще большие.
Решая академические / нефатальные проблемы, не стоит создавать
реальные / фатальные.

PS: все, заткнулся.

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

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

Re: [devel] Патч на libtool про link_all_deplibs

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 05:51:42PM +0300, Sergey V Turchin wrote:
Content-Description: signed data
> > Она, скорее всего, поднимает плагины через какую-либо KDEшную
> > обвязку, которая, в свою очередь, дергает ltdl
> Да, в нынешнем виде там в имени файла s/\.la$/.so/ делается только.
Ломается загрузка модулей. Она же (ltdl) пытается "умным" name
mangling'ом заниматься, разводя конфликты имен при помощи префиксов,
которые как раз из берутся из .la файлов.

> > . В своем нынешнем
> > виде (без .la файлов, и не захаченная нездравым способом) libltdl
> > в AltLinux
> Я собираю с %undefine __libtoolize, с libtool из исходных тарболов.
> Патчи для замены lt_dlopen на dlopen не прикладываю,
> т.к. не выявил разницы в работоспособности.
См. выше. Если кто-то захочет воспользоваться ltdl'ем именно как
загрузчиком модулей, ничего не выйдет. Попробуйте сами тестовый
примерчик накатать, там с десяток строк, выдернутых, к тому же,
из autobook'а.


> > На самом деле, я С ИНТЕРЕСОМ выслушаю ВСЕ претензии по поводу
> > софта, который собирался, но перестал после libtoolize --copy
> > --force (без aclocal). И попробую эти претензии разрешить.
Ну, я уже увидел одну проблему, которую, в общем, необходимо решать.
Проблему увидел, пока собирал для Миши xmms (Кстати, Миша, я не смотрел,
Вы патч про aclocal-mess включили в сборку? Его бы подправить радикально
надо :-)).

Проблема заключается в том, что механизм aclocal изначально не слишком
рассчитан на разделение между разработчиком и дистрибьютором. Как
следствие, если дистрибьютор вынужден по каким-либо причинам говорить
aclocal, то он, строго говоря, _обязан_ иметь тот же build environment,
что и разработчик, со всеми .m4, которые последнему были нужны. Иначе
после aclocal просто не найдется половина используемых ac-макросов.

Чтобы этого избежать некоторые, хе-хе, добрые разработчики решили класть
себе в acinclude.m4 чуть ли не весь свой /usr/share/aclocal/ & Co.

В результате, мы избежав Сциллы попадаем прямиком к Харибде, когда
макросы из acinclude.m4 просто не подходят для данной сборочной системы,
а макросы, которые установлены вместе с -devel пакетами просто
игнорируются при aclocal.

Типичные симптомы видны как раз на libtool: 

если пакет облибтулайзивался при помощи libtool-1.4 и включает в себя
копию libtool.m4 46-го разлива (т.е. от lt-1.4), то ltmain.sh от
libtool-1.5 не годится для такого пакета без дополнительных действий,
а именно, необходимо вычистить acinclude.m4 от всех "не своих" макросов,
и только затем говорить aclocal. Впрочем, кажется, я пока писал это все,
придумал решение:

что если говорить не просто

aclocal

, а, скажем, делать следующее:

переименовывать acinclude.m4, в, скажем, acinclude_local.m4, а затем
делать так:

aclocal -I `aclocal --print-ac-dir` -I .

Таким образом, все найденные системные макросы будут иметь приоритет
перед теми, которые разработчики умудрились впихнуть себе. С другой
стороны, конечно, по сусалам надо бить за такое включение, и за способ
его обруливания :-)).


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

Re: [devel] Патч на libtool про link_all_deplibs

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 06:08:09PM +0300, Dmitry V. Levin wrote:
> > и не захаченная нездравым способом) libltdl в AltLinux не рабочая (то есть,
> > не отвечает собственной спецификации и докам). В общем:
> Напомните мне, что именно в этом ltdl ломается при отсутствии .la-файлов?
name mangling

file:///usr/share/doc/autobook-1.3/autobook_173.html#SEC173


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

Re: [devel] Патч на libtool про link_all_deplibs

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 06:06:44PM +0300, Dmitry V. Levin wrote:
> On Tue, Jan 06, 2004 at 04:27:57PM +0600, Alexey Morozov wrote:
> > Так что, .la-файлы можно заковыривать обратно, никому они сильно мешать
> > уже не должны (а k3b, н-р, снова заработает, и остальные, которым
> > _действительно_ нужна функциональность libltdl)
> Кстати говоря, ещё один аргумент против .la-файлов - это избыточность.
> Их на самом деле можно восстановить прямо по разделяемым библиотекам.
Нет. Аргументация нужна, или сами в доки залезете? :-)


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

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

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 06:03:42PM +0300, Dmitry V. Levin wrote:
> > Могут. Но мне проще читать багтрек [...]
> Это вам легче.
> 
> А вот мне тогда и недели (или двух - не помню точно) форы не хватило,
> чтобы отыскать все кривые пакеты, которые носят с собой модифицированные
> версии zlib'а неизвестно какой версии.
Вполне верю. Разные, тык-скыть, профессии. С другой стороны, я надеюсь,
Вы не заставляете меня глядеть на мир Вашими глазами? :-)


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

[devel] Re: Патч на libtool про link_all_deplibs

[Michael Shigorin]

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

On Thu, Jan 08, 2004 at 09:43:27PM +0600, Alexey Morozov wrote:
> Проблему увидел, пока собирал для Миши xmms (Кстати, Миша, я не
> смотрел, Вы патч про aclocal-mess включили в сборку? Его бы
> подправить радикально надо :-)).

Вложил, но не прикладывал -- пометил "как libtool поправят" в
changelog.

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

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

Re: [devel] .a vs .so

[Dmitry V. Levin]

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

On Thu, Jan 08, 2004 at 08:36:55PM +0600, Alexey Morozov wrote:
[...]
> Дмитрий, Вы правда хотите, чтобы все, кто [был] несогласен с Вашими
> решениями, шли искать счастья в другом месте? Вам, как человеку, не
> первый день крутящемуся в вареве линукс/open source девелопмента, думаю,
> не надо рассказывать, что позиция разработчиков, выдержанная в стиле:
> 
> "Я Д'Артаньян, а вы все презервативы" и
> "- мама, я не люблю мою маленькую сестренку!
>  - ешь, что дают!", -
>  
> контрпродуктивна прежде всего для всех участников процесса. И в первую
> очередь, для самих разработчиков в частности. А проекты такие, по моему
> опыту, просто тихо дохнут, несмотря на все свои технологические
> преимущества.

Есть люди, которые, будучи несогласными, спорят по-существу.
В ALT их, я надеюсь, большинство, и с некоторыми из них вы знакомы. :)

Однако есть и такие, которым просто не нравится, когда что-то не работает,
они путают Sisyphus с продуктом, им нужно, чтобы всё и сразу.
Вот таким нетерпеливым я предлагаю заняться чем-нибудь другим, ибо
любой продукт, находящийся в стадии разработки (а Сизиф - это именно
стадия разработки), имеет такую особенность - про него нельзя сказать, что
в нём работает всё и сразу.  Если вам нужен продукт - не пользуйтесь
Сизифом.

> Вы смотрели на присланный мною патч?

Я его потестирую.

> Как Вам кажется, он способен решить
> проблему с обязательным перестроением autotools'ового барахла, или надо
> еще что-то дополнительно придумывать?

Есть одна маленькая проблема: у нас почти весь KDE собирается с
"%undefine __libtoolize".  Я не знаю, почему, я не maintainer KDE.

> И если способен, то не пора ли
> объявить план перехода на _нормальную_ сборочную систему. Я не настаиваю
> на том, чтобы все разом бросились "вертать все взад", но и нынешнее
> положение вещей меня не устраивает. И, как видно, не только меня.

Я знаю, что по разделяемым библиотекам можно восстановить все .la-файлы, в
том числе и те, которых вообще никогда не существовало.

Может быть, из этого можно придумать другое решение задачи?


-- 
ldv

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

Re: [devel] .a vs .so

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 07:03:32PM +0300, Dmitry V. Levin wrote:
> Есть люди, которые, будучи несогласными, спорят по-существу.
> В ALT их, я надеюсь, большинство, и с некоторыми из них вы знакомы. :)
Ну, вот и договорились :-)

> > Вы смотрели на присланный мною патч?
> Я его потестирую.
Ok.

> > Как Вам кажется, он способен решить
> > проблему с обязательным перестроением autotools'ового барахла, или надо
> > еще что-то дополнительно придумывать?
> Есть одна маленькая проблема: у нас почти весь KDE собирается с
> "%undefine __libtoolize".  Я не знаю, почему, я не maintainer KDE.
Ну, я уже описал в ответе Сергею, в чем там очередные libtool'овые
грабли, и как и можно попробовать обойти. Во что это выльется на самом
деле, сказать не могу, но по опыту разборок с mosfet-liquid - работает
(в смысле libtoolize), причем, количество и сложность усилий по запиныванию
вполне приемлемы.

Там главное понять, как эта вся помойка функционирует, после чего с ней
можно делать все, что угодно :-).
"What is he going?? He's starting to believe"


> > И если способен, то не пора ли
> > объявить план перехода на _нормальную_ сборочную систему. Я не настаиваю
> > на том, чтобы все разом бросились "вертать все взад", но и нынешнее
> > положение вещей меня не устраивает. И, как видно, не только меня.
> Я знаю, что по разделяемым библиотекам можно восстановить все .la-файлы, в
> том числе и те, которых вообще никогда не существовало.
> 
> Может быть, из этого можно придумать другое решение задачи?
Придумать-то можно. Только "куда думать"? В смысле, чего хочется
добиться в результате, и чем не устраивает то, что проталкиваю я. Тогда
и другое решение можно будет предложить.


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

Re: [devel] Re: Патч на libtool про link_all_deplibs

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 05:57:52PM +0200, Michael Shigorin wrote:
> > Проблему увидел, пока собирал для Миши xmms (Кстати, Миша, я не
> > смотрел, Вы патч про aclocal-mess включили в сборку? Его бы
> > подправить радикально надо :-)).
> Вложил, но не прикладывал -- пометил "как libtool поправят" в
> changelog.
На самом деле, пофиг. "Оно не должно ничего сломать" (TM).
Только, конечно, сократить этот патч надо кардинально :-)).

<offtopic>
Вообще, похоже, весь мировой экспириенс по autotools делился крайне
неравномерно. Махоткину вон досталось 3/4 всего российского, а большей
части разработчиков, похоже, вообще ничего не перепало. Отсюда и траблы :-)
</offtopic>


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

Re: [devel] .a vs .so

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 10:14:04PM +0600, Alexey Morozov wrote:
> > Есть одна маленькая проблема: у нас почти весь KDE собирается с
> > "%undefine __libtoolize".  Я не знаю, почему, я не maintainer KDE.
> Ну, я уже описал в ответе Сергею, в чем там очередные libtool'овые
> грабли, и как и можно попробовать обойти. Во что это выльется на самом
Поправочка: autotools'овые грабли.


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

Re: [devel] .a vs .so

[Sergey V Turchin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 412 bytes --]

В сообщении от 8 Январь 2004 19:03 Dmitry V. Levin написал(a):

<skip/>

> Есть одна маленькая проблема: у нас почти весь KDE собирается с
> "%undefine __libtoolize".  Я не знаю, почему, я не maintainer
> KDE.
Без него ломается сборка, это тянется еще с kde2.2.2 libtool-1.4 :-(

<skip/>

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] .a vs .so

[Sergey V Turchin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 763 bytes --]

В сообщении от 8 Январь 2004 19:14 Alexey Morozov написал(a):

<skip/>

> Ну, я уже описал в ответе Сергею, в чем там очередные
> libtool'овые грабли, и как и можно попробовать обойти. Во что это
> выльется на самом деле, сказать не могу, но по опыту разборок с
> mosfet-liquid - работает (в смысле libtoolize), причем,
> количество и сложность усилий по запиныванию вполне приемлемы.
>
> Там главное понять, как эта вся помойка функционирует, после чего
> с ней можно делать все, что угодно :-).
> "What is he going?? He's starting to believe"
Покажете patch на mosfet-liquid? Буду исправляться.
Если не пойму, спрошу подробнее.

<skip/>

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] Патч на libtool про link_all_deplibs

[Dmitry V. Levin]

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

On Thu, Jan 08, 2004 at 09:51:11PM +0600, Alexey Morozov wrote:
> On Thu, Jan 08, 2004 at 06:06:44PM +0300, Dmitry V. Levin wrote:
> > On Tue, Jan 06, 2004 at 04:27:57PM +0600, Alexey Morozov wrote:
> > > Так что, .la-файлы можно заковыривать обратно, никому они сильно мешать
> > > уже не должны (а k3b, н-р, снова заработает, и остальные, которым
> > > _действительно_ нужна функциональность libltdl)
> > Кстати говоря, ещё один аргумент против .la-файлов - это избыточность.
> > Их на самом деле можно восстановить прямо по разделяемым библиотекам.
> Нет. Аргументация нужна, или сами в доки залезете? :-)

Нет, не полезу. :)
Если есть контрпример, давайте его сюда.


-- 
ldv

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

Re: [devel] Патч на libtool про link_all_deplibs

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 08:23:53PM +0300, Dmitry V. Levin wrote:
> > > Кстати говоря, ещё один аргумент против .la-файлов - это избыточность.
> > > Их на самом деле можно восстановить прямо по разделяемым библиотекам.
> > Нет. Аргументация нужна, или сами в доки залезете? :-)
> Нет, не полезу. :)
> Если есть контрпример, давайте его сюда.
Статические библиотеки. Модули. Собственно, все то, ради чего
ltdl и придумывался. То есть, в том виде, в котором он сейчас в Сизифе
используется, его проще пристрелить, чем править. Впрочем, я уже
повторяюсь.



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

Re: [devel] Патч на libtool про link_all_deplibs

[Dmitry V. Levin]

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

On Thu, Jan 08, 2004 at 09:43:27PM +0600, Alexey Morozov wrote:
> [...] Впрочем, кажется, я пока писал это все, придумал решение:
> 
> что если говорить не просто
> 
> aclocal
> 
> , а, скажем, делать следующее:
> 
> переименовывать acinclude.m4, в, скажем, acinclude_local.m4, а затем
> делать так:
> 
> aclocal -I `aclocal --print-ac-dir` -I .
>
> Таким образом, все найденные системные макросы будут иметь приоритет
> перед теми, которые разработчики умудрились впихнуть себе. С другой
> стороны, конечно, по сусалам надо бить за такое включение, и за способ
> его обруливания :-)).

Тогда уж так:

mkdir -p m4
mv *.m4 m4
aclocal -I `aclocal --print-ac-dir` -I m4

А если кто-то кастомизировал системный макрос, то такому автору надо...
нет, ничего ему уже не надо. :(


-- 
ldv

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

Re: [devel] .a vs .so

[Dmitry V. Levin]

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

On Thu, Jan 08, 2004 at 10:14:04PM +0600, Alexey Morozov wrote:
[...]
> > Я знаю, что по разделяемым библиотекам можно восстановить все .la-файлы, в
> > том числе и те, которых вообще никогда не существовало.
> > 
> > Может быть, из этого можно придумать другое решение задачи?
> Придумать-то можно. Только "куда думать"? В смысле, чего хочется
> добиться в результате, и чем не устраивает то, что проталкиваю я. Тогда
> и другое решение можно будет предложить.

Что нам даёт удаление всех .la-файлов к разделяемым библиотекам, помимо
решения основной задачи (недопущение превращения косвенных зависимостей
в прямые)?  Гарантию того, что эти самые косвенные зависимости через
.la-файлы не попадут в собираемые программы и библиотеки.  Тот способ,
который вы предлагаете, не даёт такой твёрдой гарантии просто потому,
что надо в каждом конкретном случае убеждаться, что способ применён
правильно.

Чего хочется добиться?  Решения этой задачи с лишними зависимостями
(которые, как мы знаем, могут порождать жуткие проблемы в runtime), не
вдаваясь в особенности устройства кривизны каждого пакета в Сизифе. 

Как при этом сохранить возможность линковать статические приложения?
Запаковывать по одному .la-файлу в пакет тоже ведь не очень хочется.
Я предположил, что их можно просто восстанавливать скриптом при
необходимости по уже установленным разделяемым библиотекам.


-- 
ldv

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

Re: [devel] Патч на libtool про link_all_deplibs

[Dmitry V. Levin]

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

On Wed, Jan 07, 2004 at 02:12:25AM +0600, Alexey Morozov wrote:
[...]
> > > формате и порядке использования всяких общеупотребительных параметров, типа
> > > with_static, with_kde, with_gnome итп. Кому надо, будут пользоваться, а то
> > > сейчас - кто в лес, кто по дрова.
> > Я не против.
> Ладно, я для себя попробую сделать, если что получится здравое - расскажу.

Кстати говоря, добавление строки
%_enable_static --enable-static
в ~/.rpmmacros тоже будет работать, причём для всех пакетов, для которых
работает включение статики через "--enable static".


-- 
ldv

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

Re: [devel] .a vs .so

[Vitaly Lipatov]

On 8 Январь 2004 23:14, Dmitry V. Levin wrote:
> Как при этом сохранить возможность линковать статические
> приложения? Запаковывать по одному .la-файлу в пакет тоже ведь
> не очень хочется. Я предположил, что их можно просто
> восстанавливать скриптом при необходимости по уже
> установленным разделяемым библиотекам.
А предложение запаковывать их в -static очень глупо звучит?
-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] .a vs .so

[Dmitry V. Levin]

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

On Fri, Jan 09, 2004 at 01:21:39AM +0300, Vitaly Lipatov wrote:
> On 8 Январь 2004 23:14, Dmitry V. Levin wrote:
> > Как при этом сохранить возможность линковать статические
> > приложения? Запаковывать по одному .la-файлу в пакет тоже ведь
> > не очень хочется. Я предположил, что их можно просто
> > восстанавливать скриптом при необходимости по уже
> > установленным разделяемым библиотекам.
> А предложение запаковывать их в -static очень глупо звучит?

Тогда (если не был выполнен правильный aclocal+libtoolize) результат 
сборки динамической библиотеки будет зависеть от того, установлена ли в
сборочной системе статическая библиотека, несмотря на то, что она для
сборки динамической библиотеки не используется.

Это называется "undefined behaviour", таких вещей стоит избегать.


-- 
ldv

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

Re: [devel] Патч на libtool про link_all_deplibs

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 08:32:34PM +0300, Dmitry V. Levin wrote:
> > aclocal -I `aclocal --print-ac-dir` -I .
> Тогда уж так:
> 
> mkdir -p m4
> mv *.m4 m4
> aclocal -I `aclocal --print-ac-dir` -I m4
Да, так будет лучше.

> А если кто-то кастомизировал системный макрос, то такому автору надо...
> нет, ничего ему уже не надо. :(
:-)
Ну, чистится это. Немного тупой, механической работы при пересборке.
Я так понимаю, QA Robot сейчас подкидывает мэйнтэйнерам существенно
больше ;-)


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

[devel] Re: .a vs .so

[Michael Shigorin]

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

On Fri, Jan 09, 2004 at 02:22:44AM +0300, Dmitry V. Levin wrote:
> > А предложение запаковывать их в -static очень глупо звучит?
> Тогда (если не был выполнен правильный aclocal+libtoolize)
> результат сборки динамической библиотеки будет зависеть от
> того, установлена ли в сборочной системе статическая
> библиотека, несмотря на то, что она для сборки динамической
> библиотеки не используется.
> 
> Это называется "undefined behaviour", таких вещей стоит
> избегать.

Обязать (policy/lint) дергать aclocal+libtoolize, для удобства
обвязав макросом или вообще подоткнув по умолчанию (отключаемо
для спецчлучаев) в %configure?

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

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

Re: [devel] Патч на libtool про link_all_deplibs

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 11:19:51PM +0300, Dmitry V. Levin wrote:
> > Ладно, я для себя попробую сделать, если что получится здравое - расскажу.
> Кстати говоря, добавление строки
> %_enable_static --enable-static
> в ~/.rpmmacros тоже будет работать, причём для всех пакетов, для которых
> работает включение статики через "--enable static".
Да, самое здравое решение, пожалуй.


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

Re: [devel] .a vs .so

[Alexey Morozov]

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

On Thu, Jan 08, 2004 at 11:14:57PM +0300, Dmitry V. Levin wrote:
> Что нам даёт удаление всех .la-файлов к разделяемым библиотекам, помимо
> решения основной задачи (недопущение превращения косвенных зависимостей
> в прямые)?  Гарантию того, что эти самые косвенные зависимости через
> .la-файлы не попадут в собираемые программы и библиотеки.
Ну, нынаю... Автотест работает, могу свои тесты формализовать и добавить
к стандартным libtool'овским, что еще проверять, чес-гря, не знаю.
Мои тесты, напомню, показали (на depdemo/), что gcc на линковке получает
все те библиотеки, которые потребны ему для данного вида сборки
(то есть, в динамической сборке libl3 НЕ передается, а в статической -
передается).

Если предложите "плохую" ситуацию, которую надо промоделировать, эту
проверку тоже можно будет отправить в libtool'овые тесты.

> Тот способ, который вы предлагаете, не даёт такой твёрдой гарантии
> просто потому, что надо в каждом конкретном случае убеждаться, что
> способ применён правильно.
Думаю, нет. libtoolize --copy --force позволяет, с одной стороны,
заменить "неправильные" ltmain.sh на "правильные", а с другой
рубит тех, кто пришел с libtool-1.4 в потрохах.

aclocal -I `aclocal ...` -I m4

позволяет обойти и тех последних. В общем, думаю, в нынешней ситуации
все равно приходится разбираться некоторыми пакетами, причем, с теми,
кто _делает все правильно_.

В моём способе разбираться приходится с теми, кто делает что-либо
неправильно. По-моему, альтернатива более здравая. Я, если пороюсь
в здешних архивах, накопаю Ваше письмо о том, что Вы готовы бороться
за правильные решения :-)).

> Чего хочется добиться?  Решения этой задачи с лишними зависимостями
> (которые, как мы знаем, могут порождать жуткие проблемы в runtime), не
> вдаваясь в особенности устройства кривизны каждого пакета в Сизифе.
Нет, это неполная постановка задачи. Требуется детализация.

> Как при этом сохранить возможность линковать статические приложения?
> Запаковывать по одному .la-файлу в пакет тоже ведь не очень хочется.
Я предложил бы паковать все.

> Я предположил, что их можно просто восстанавливать скриптом при
> необходимости по уже установленным разделяемым библиотекам.
В какой момент? Теоретически, конечно, такая возможность есть, но,
по-моему, это странно: сначала откзываться от какой-либо информации,
потом ее вытаскивать по каким-либо "внешним" факторам. К тому же,
я не уверен, что если в зависимости для _динамических_ библиотек
попадет какая-либо чисто статическая (ну, вообщем-то, такое устроить
можно запросто), то мы не потеряем в этом месте информацию безвозвратно.

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

Re: [devel] .a vs .so

[Dmitry V. Levin]

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

On Fri, Jan 09, 2004 at 03:46:19PM +0600, Alexey Morozov wrote:
> On Thu, Jan 08, 2004 at 11:14:57PM +0300, Dmitry V. Levin wrote:
> > Что нам даёт удаление всех .la-файлов к разделяемым библиотекам, помимо
> > решения основной задачи (недопущение превращения косвенных зависимостей
> > в прямые)?  Гарантию того, что эти самые косвенные зависимости через
> > .la-файлы не попадут в собираемые программы и библиотеки.
> Ну, нынаю... Автотест работает, могу свои тесты формализовать и добавить
> к стандартным libtool'овским, что еще проверять, чес-гря, не знаю.
> Мои тесты, напомню, показали (на depdemo/), что gcc на линковке получает
> все те библиотеки, которые потребны ему для данного вида сборки
> (то есть, в динамической сборке libl3 НЕ передается, а в статической -
> передается).
> 
> Если предложите "плохую" ситуацию, которую надо промоделировать, эту
> проверку тоже можно будет отправить в libtool'овые тесты.

Если найду, то конечно предложу.

> > Тот способ, который вы предлагаете, не даёт такой твёрдой гарантии
> > просто потому, что надо в каждом конкретном случае убеждаться, что
> > способ применён правильно.
> Думаю, нет. libtoolize --copy --force позволяет, с одной стороны,
> заменить "неправильные" ltmain.sh на "правильные", а с другой
> рубит тех, кто пришел с libtool-1.4 в потрохах.
> 
> aclocal -I `aclocal ...` -I m4
> 
> позволяет обойти и тех последних. В общем, думаю, в нынешней ситуации
> все равно приходится разбираться некоторыми пакетами, причем, с теми,
> кто _делает все правильно_.

Нет, не приходится.  Как правило, достаточно слепой пересборки.

> В моём способе разбираться приходится с теми, кто делает что-либо
> неправильно. По-моему, альтернатива более здравая. Я, если пороюсь
> в здешних архивах, накопаю Ваше письмо о том, что Вы готовы бороться
> за правильные решения :-)).

Конечно.  Не знаю, правда, как отнесутся maintainer'ы на (вообще говоря,
правильное) предложение всегда использовать "libtoolize --force".
Не знаю, насколько это пройдёт гладко.  Поэтому и уверенности нет.

> > Чего хочется добиться?  Решения этой задачи с лишними зависимостями
> > (которые, как мы знаем, могут порождать жуткие проблемы в runtime), не
> > вдаваясь в особенности устройства кривизны каждого пакета в Сизифе.
> Нет, это неполная постановка задачи. Требуется детализация.

В Сизифе очень много кривых пакетов, в которых никому, кроме разве что
их maintainer'ов, копаться не хочется.  Нужен способ по возможности
избежать перелопачивания этого множества кривых пакетов, ибо это может
оказаться неподъёмной задачей на данном этапе.

> > Как при этом сохранить возможность линковать статические приложения?
> > Запаковывать по одному .la-файлу в пакет тоже ведь не очень хочется.
> Я предложил бы паковать все.

Как раньше, или как-то иначе?

> > Я предположил, что их можно просто восстанавливать скриптом при
> > необходимости по уже установленным разделяемым библиотекам.
> В какой момент? Теоретически, конечно, такая возможность есть, но,
> по-моему, это странно: сначала откзываться от какой-либо информации,
> потом ее вытаскивать по каким-либо "внешним" факторам. К тому же,
> я не уверен, что если в зависимости для _динамических_ библиотек
> попадет какая-либо чисто статическая (ну, вообщем-то, такое устроить
> можно запросто), то мы не потеряем в этом месте информацию безвозвратно.

Неужели такое встречается в реальной практике?


-- 
ldv

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

[devel] Re: .a vs .so

[Michael Shigorin]

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

On Sat, Jan 10, 2004 at 03:08:08AM +0300, Dmitry V. Levin wrote:
> Конечно.  Не знаю, правда, как отнесутся maintainer'ы на
> (вообще говоря, правильное) предложение всегда использовать
> "libtoolize --force".

Говоря за себя... и так местами используется (например, взяв из
Cooker/PLD/... spec и убедившись, что собирается нормально).

Если будет зафиксировано как рекомендация/требование с пояснением
сути и (диагностики) возможных вариантов -- еще лучше.

Добавить одну строчку обычно проще, чем биться головой об монитор
:-)

> Не знаю, насколько это пройдёт гладко.  Поэтому и уверенности
> нет.

Давайте попробуем на форке сизифа, желательно до времен la wars.

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

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

[devel] Re: .a vs .so

[Mikhail Zabaluev]

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

Hello Alexey,

On Thu, Jan 08, 2004 at 08:19:47PM +0600, Alexey Morozov wrote:
>
> Хех. То-то, как кто-нибудь возьмется что-либо посложнее в бинарном виде
> распространять, так и кладет статику, как last resort.

Ключевые слова "в бинарном виде".
А если уж есть статический build, какие вообще проблемы с библиотеками?
Если каким-то бинарным пакетам нужны какие-то замшелые soname,
об этом нужно писать feature requests в http://bugzilla.altlinux.ru

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
"It is the creationists who blasphemously are claiming that God is cheating
 us in a stupid way."
-- J. W. Nienhuys

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

Re: [devel] .a vs .so (was Re: ðÁÔÞ ÎÁ libtool ÐÒÏ link_all_deplibs)

[Alex Ott]

Hi all

>>>>> "AM" == Alexey Morozov writes:
 AM> И это я еще не говорю о том, что этих чертовых линуксов на самом деле
 AM> - хоть пруд пруди. Можно сделать пятьдесят билдов, и все равно
 AM> останется кто-то, кто начнет гундеть: а вот под мой любимый
 AM> SuperCoolLinux у вас нет сборки.

Хех - у меня теже проблемы с поддержкой софта.

 >> Более того, статические библиотеки могут быть контрпродуктивны.
 >> Вспомните историю с багом в zlib.
 AM> Могут. Но мне проще читать багтрек, чем в десять вечера начинать
 AM> понимать, что и где там сломалось в очередной раз, от того, что кто-то
 AM> не думая, чего-то поменял в системе.

Вот тут я поддерживаю. Мне как человеку поддерживающему сборки под кучу
линуксов (а также FreeBSD, HP-UX, Solaris) удобней использовать статические
библиотеки. 

-- 
With best wishes, Alex Ott
-------------------------------
Jet Infosystems, Moscow, Russia    mailto: ottalex@narod.ru
http://xtalk.msk.su/~ott/          ICQ #22005116

[devel] Re: .a vs .so

[Mikhail Zabaluev]

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

Hello Dmitry,

On Thu, Jan 08, 2004 at 11:14:57PM +0300, Dmitry V. Levin wrote:
>
> Как при этом сохранить возможность линковать статические приложения?
> Запаковывать по одному .la-файлу в пакет тоже ведь не очень хочется.
> Я предположил, что их можно просто восстанавливать скриптом при
> необходимости по уже установленным разделяемым библиотекам.

А можно восстановить чистильщика .la файлов, который помимо удаления
вредных -L будет удалять и -l, которые прописаны в .so. Правда,
по неясному мне принципу в dependency_libs попадают и
.la-файлы. Осмелюсь предположить, что такие зависимости вызваны ленью
и/или недостаточной компетентностью разработчиков upstream, и такие
зависимости можно безжалостно вырезать по принципу "быстрее сломается
-- быстрее исправят".
Не получится ли у нас таким образом и рыбку съесть, и из аквариума
запить?

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
I can't understand why people are frightened of new ideas.  I'm frightened
of the old ones.
		-- John Cage

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

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

[Alexey Morozov]

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

On Sat, Jan 10, 2004 at 02:19:50PM +0300, Mikhail Zabaluev wrote:
> > Хех. То-то, как кто-нибудь возьмется что-либо посложнее в бинарном виде
> > распространять, так и кладет статику, как last resort.
> Ключевые слова "в бинарном виде".
Увы и ах. "Меня не поймут", если я предложу клиентам source-based
дистрибуцию. Причем, сами клиенты и не поймут. На.... им надо
заморачиваться какими-то там gcc, autoconf и прочей разной требухой.

Причем, как я уже говорил, на отдачу сорцов влияют совсем другие факторы,
нежели просто opensource/commercial модели распространения софта.

> А если уж есть статический build, какие вообще проблемы с библиотеками?
> Если каким-то бинарным пакетам нужны какие-то замшелые soname,
> об этом нужно писать feature requests в http://bugzilla.altlinux.ru
То есть, если у меня штуковина, собранная на ALT, не запускается на RH,
то мне надо писать на bugzilla.altlinux.ru? А там обрадуются такой моей
cамодеятельности? :-))

P.S. Пора с этим валить отсюда. Все равно треп уже неконструктивный.


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

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

[Alexey Morozov]

[-- 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 --]

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

[Alexey Morozov]

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

On Sat, Jan 10, 2004 at 09:01:34AM +0200, Michael Shigorin wrote:
> On Sat, Jan 10, 2004 at 03:08:08AM +0300, Dmitry V. Levin wrote:
> > Конечно.  Не знаю, правда, как отнесутся maintainer'ы на
> > (вообще говоря, правильное) предложение всегда использовать
> > "libtoolize --force".
> Говоря за себя... и так местами используется (например, взяв из
> Cooker/PLD/... spec и убедившись, что собирается нормально).
См. дискуссию про необходимость и способы запуска aclocal.

При использовании libtoolize необходимо использовать соответствующие
версии libtool-макросов.

В принципе, конечно, можно сказать, что сейчас в природе (в пакетах)
существуют либо libtool-1.4, либо libtool-1.5.

Соответственно, можно говорить не libbtolize ..., а libtoolize-<version>,
в зависимости от версии libtool, используемой данным пакетом (проверять
по VERSION в ltmain.sh или serial в соответствующем макросе).

Тогда и от вынужденного aclocal; autoconf можно будет отказаться.

> Если будет зафиксировано как рекомендация/требование с пояснением
> сути и (диагностики) возможных вариантов -- еще лучше.
Диагностика:

после libtoolize-1.5 в пакете, для которого не обновлены m4-макросы,
сборка вываливается при запуске libtool и диагностикой:

./libtool: line 1: s%^.*/%%: No such file or directory
./libtool: line 1: -e: command not found
...
./libtool: line 1: -e: command not found

(в ltmain.sh-1.5 используется ${SED} вместо прямого вызова sed в 1.4)

Способ лечения:

mkdir -p m4
mv *.m4 m4/
aclocal -I `aclocal --print-ac-dir` -I m4 [-I все остальные локальные m4-директории]
autoconf

либо просто использовать libtool-1.4, но его еще нужно будет править на предмет
невключения ненужных зависимостей. Возможно, патчем этого самого Scott James
Remnant.

> > Не знаю, насколько это пройдёт гладко.  Поэтому и уверенности
> > нет.
> Давайте попробуем на форке сизифа, желательно до времен la wars.
Угу.


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

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

[Dmitry V. Levin]

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

On Sun, Jan 11, 2004 at 08:23:29AM +0600, Alexey Morozov wrote:
> On Sun, Jan 11, 2004 at 01:23:11AM +0300, Mikhail Zabaluev wrote:
[...]
> 5. После обнаружения .la-файла, оригинальный (неправленный Альтом) libtool
> использует информацию из dependency_libs для рекурсивного разворачивания
> цепочки зависимостей библиотек до самого низа. При этом очевидно, что
> при некоторых условиях возможна ситуация, когда одновременно линкеру
> передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)).

Аналогичная история с libpng была удостоена упоминания в fortunes-ALT.

> Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными
> Последствиями" для базы rpm, в частности. (В скобках замечу, что
> многообразие libdb лично у меня вызывает довольно негативную реакцию.
> С другой стороны, по опыту KSI знаю, что приведение системы в консистентное
> состояние в данном вопросе приводит к массе усилий, больше напоминающих
> войну с ветряными мельницами. Зато некоторое время "Все Правильно" :-))

Да, по поводу многобез^H^H^Hобразия libdb грустят все вендоры, ибо
хорошего решения пока не найдено.

[...]
> 9. Сейчас Дмитрием предложена схема, когда .la-файлы сохраняются, однако
> информация о dependency_libs из них [как правило] удаляется, а в случае
> необходимости (для статических сборок, н-р), насчитывает на основании
> зависимостей динамических аналогов статических библиотек.

Нет, я не это предлагал.  
Если пренебречь проблемой 7.2 (в реальности которой я не уверен), и
ограничиться решением проблем 7.1 и 7.3 (которые возникают после удаления
системных .la-файлов к разделяемым библиотекам), то .la-файлы к
разделяемым библиотекам можно восстанавливать по самим разделяемым
библиотекам.

Это даёт возможность либо паковать эти .la-файлы отдельно, либо не паковать
вообще, а воссоздавать отдельно, либо по мере надобности, либо автоматически
по окончании установки пакетов, вызывающих /sbin/ldconfig.


-- 
ldv

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

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

[Алексей Любимов]

>5. После обнаружения .la-файла, оригинальный (неправленный Альтом) libtool
>использует информацию из dependency_libs для рекурсивного разворачивания
>цепочки зависимостей библиотек до самого низа. При этом очевидно, что
>при некоторых условиях возможна ситуация, когда одновременно линкеру
>передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)).
>
Вопрос
а если в системе стоят только  libdb4.0 и libdb4.1, libdb4.1-devel (со 
статиком)
будет подхвачена libdb4.0?

>
>Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными
>Последствиями" для базы rpm, в частности.
>
А bte зачем делали?

>7.2. Во-вторых, вне зависимости от характера линковки, нам, строго говоря,
>_необходима_ информация, записанная в  dependency_libs. Необходимость
>этой информации обусловлена [достаточно гипотетической, впрочем]
>возможностью наличия в зависимостях статической библиотеки без
>соответствующего динамического аналога (я припоминаю, что, вроде, то ли
>libkrb, то ли libsocks [некогда] распространялся в таком вот виде). Плюс
>всякие third-party, но это уже их головная боль, наверное.
>  
>
другими словами, даже деление на devel и devel-static с последующей 
неустановкой *-static для  сборки программы с динамической линковкой в 
общем случае некорректно?


>7.3. Во-третьих, кроме dependency libs, содержимое .la-файла (конкретно,
>имя библиотеки) используется libtool'ом для обеспечения корректной работы
>с ltdl-модулями (см. autobook)
>
Предыдущее предположение и здесь в силе?

>
>8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5.
>libtool подправлен таким образом, чтобы при динамической сборке на линуксе
>список dependency_libs не раскрывался вовсе (при статической все по-прежнему).
>Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере,
>вроде бы, решает все остальные.
>
А почему нельзя на этапе сборки просто ограничить выбор пакетов 
правильными зависимостями в спеке? Разве это не ограничит выбор 
dependency_libs?

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

[Alexei Takaseev]

On Sun, 11 Jan 2004 17:44:30 +0300
Алексей Любимов <avl@l14.ru> wrote:

> 
> >5. После обнаружения .la-файла, оригинальный (неправленный Альтом)
> >libtool использует информацию из dependency_libs для рекурсивного
> >разворачивания цепочки зависимостей библиотек до самого низа. При
> >этом очевидно, что при некоторых условиях возможна ситуация, когда
> >одновременно линкеру передаются две версии одной и той же библиотеки
> >(н-р, libdb4.x :-)).
> >
> Вопрос
> а если в системе стоят только  libdb4.0 и libdb4.1, libdb4.1-devel (со
> статиком) будет подхвачена libdb4.0?

Вполне возможно что и подхватится. Правда у меня другая ситуация была -
в системе установлены libdb4.0, libdb4.1 и libdb4.0-devel, приложение
надо собрать именно с libdb4.0. При линковке происходит подцеплением
libdb4.1.

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

[Алексей Любимов]

Alexei Takaseev пишет:

>On Sun, 11 Jan 2004 17:44:30 +0300
>Алексей Любимов <avl@l14.ru> wrote:
>
>  
>
>>>5. После обнаружения .la-файла, оригинальный (неправленный Альтом)
>>>libtool использует информацию из dependency_libs для рекурсивного
>>>разворачивания цепочки зависимостей библиотек до самого низа. При
>>>этом очевидно, что при некоторых условиях возможна ситуация, когда
>>>одновременно линкеру передаются две версии одной и той же библиотеки
>>>(н-р, libdb4.x :-)).
>>>
>>>      
>>>
>>Вопрос
>>а если в системе стоят только  libdb4.0 и libdb4.1, libdb4.1-devel (со
>>статиком) будет подхвачена libdb4.0?
>>    
>>
>
>Вполне возможно что и подхватится. Правда у меня другая ситуация была -
>в системе установлены libdb4.0, libdb4.1 и libdb4.0-devel, приложение
>надо собрать именно с libdb4.0. При линковке происходит подцеплением
>libdb4.1.
>
Это как раз нормально (хотя возможно и неприятно).
Правильные зависимости в спеке и bte должны решать эту проблему легко и 
пушисто.

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

[Dmitry V. Levin]

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

On Sun, Jan 11, 2004 at 05:44:30PM +0300, Алексей Любимов wrote:
> >5. После обнаружения .la-файла, оригинальный (неправленный Альтом) libtool
> >использует информацию из dependency_libs для рекурсивного разворачивания
> >цепочки зависимостей библиотек до самого низа. При этом очевидно, что
> >при некоторых условиях возможна ситуация, когда одновременно линкеру
> >передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)).
> >
> Вопрос
> а если в системе стоят только  libdb4.0 и libdb4.1, libdb4.1-devel (со 
> статиком)
> будет подхвачена libdb4.0?

Во время сборки или во время запуска?

Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L
- с библиотекой libdb4.0, то во время запуска программы A в памяти
окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны.
  
> >Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными
> >Последствиями" для базы rpm, в частности.
> >
> А bte зачем делали?

О чём это вы?  BTE - это миф.
Если программа A из предыдущего примера не используется во время сборки
других пакетов, то выявить её неработоспособность путём пересборки Сизифа
не удастся.

> >7.2. Во-вторых, вне зависимости от характера линковки, нам, строго говоря,
> >_необходима_ информация, записанная в  dependency_libs. Необходимость
> >этой информации обусловлена [достаточно гипотетической, впрочем]
> >возможностью наличия в зависимостях статической библиотеки без
> >соответствующего динамического аналога (я припоминаю, что, вроде, то ли
> >libkrb, то ли libsocks [некогда] распространялся в таком вот виде). Плюс
> >всякие third-party, но это уже их головная боль, наверное.
> >
> другими словами, даже деление на devel и devel-static с последующей 
> неустановкой *-static для  сборки программы с динамической линковкой в 
> общем случае некорректно?

В том случае, о котором идёт речь в 7.2, некорректно.
Правда, у нас в Сизифе таких всего 2:
glibc-devel (libc_nonshared.a и *crt*.o) и gcc (*crt*.o).
И надеюсь, что не будет.

> >7.3. Во-третьих, кроме dependency libs, содержимое .la-файла (конкретно,
> >имя библиотеки) используется libtool'ом для обеспечения корректной работы
> >с ltdl-модулями (см. autobook)
> >
> Предыдущее предположение и здесь в силе?

Нет.  Во время динамической загрузки можно нормально загрузить только
динамические модули.

> >8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5.
> >libtool подправлен таким образом, чтобы при динамической сборке на линуксе
> >список dependency_libs не раскрывался вовсе (при статической все 
> >по-прежнему).
> >Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере,
> >вроде бы, решает все остальные.
> >
> А почему нельзя на этапе сборки просто ограничить выбор пакетов 
> правильными зависимостями в спеке? Разве это не ограничит выбор 
> dependency_libs?

Вы предлагаете ликвидировать find-requires и перейти на указание
зависимостей собранных пакетов вручную?


-- 
ldv

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

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

[Albert R. Valiev]

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

В сообщении от 11 Январь 2004 19:01 Dmitry V. Levin написал(a):
> > А почему нельзя на этапе сборки просто ограничить выбор пакетов
> > правильными зависимостями в спеке? Разве это не ограничит выбор
> > dependency_libs?
>
> Вы предлагаете ликвидировать find-requires и перейти на указание
> зависимостей собранных пакетов вручную?

Наверное имелись в виду BuildRequires. Возможно предлагалось указывать 
конкретные версии библиотек (т.е. вместо BuildRequiresL libdb4 указывать 
libdb4.0, 4.1, etc), однако проблем это все равно не решит, пока будет 
существовать возможность линковки с библиотекой, которая в свою очередь 
слинкована с предыдущей версие libdb4 (для примера). 

-- 
With Best Regards, Albert R. Valiev
-----------------------------------
ALT Linux Team [www.altlinux.org]

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

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

[Алексей Любимов]

Dmitry V. Levin пишет:

>On Sun, Jan 11, 2004 at 05:44:30PM +0300, Алексей Любимов wrote:
>  
>
>>>5. После обнаружения .la-файла, оригинальный (неправленный Альтом) libtool
>>>использует информацию из dependency_libs для рекурсивного разворачивания
>>>цепочки зависимостей библиотек до самого низа. При этом очевидно, что
>>>при некоторых условиях возможна ситуация, когда одновременно линкеру
>>>передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)).
>>>
>>>      
>>>
>>Вопрос
>>а если в системе стоят только  libdb4.0 и libdb4.1, libdb4.1-devel (со 
>>статиком)
>>будет подхвачена libdb4.0?
>>    
>>
>
>Во время сборки или во время запуска?
>
1 момент. - Во время сборки.
При отсутствии -devel, разве может программа прилинковаться к библиотеке.


>
>Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L
>- с библиотекой libdb4.0, то во время запуска программы A в памяти
>окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны.
>  
>

То, что  вся цепочка слинкованных программ должна быть связана с одной 
версией libdb4.1 естественно.
Но проблема то поднималась другая. Лишние связи, когда при сборке 
программ могут быть подсунуты случайные версии и даже вперемешку. Разве 
не так?

Рекурсивно разворачивать во время сборки все связи и завершать сборку 
при конфликте версий через другие линкуемые библиотеки имхо совсем 
другая задача. не так?

>  
>
>>>Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными
>>>Последствиями" для базы rpm, в частности.
>>>
>>>      
>>>
>>А bte зачем делали?
>>    
>>
>
>О чём это вы?  BTE - это миф.
>Если программа A из предыдущего примера не используется во время сборки
>других пакетов, то выявить её неработоспособность путём пересборки Сизифа
>не удастся.
>  
>
Это совсем из другой оперы. Предлагается то курочить aclocal, то есть 
влиять исключительно на процесс сборки. А какой тогда в этом смысл, если 
программа в сборке просто не участвует?

>>>7.2. Во-вторых, вне зависимости от характера линковки, нам, строго говоря,
>>>_необходима_ информация, записанная в  dependency_libs. Необходимость
>>>этой информации обусловлена [достаточно гипотетической, впрочем]
>>>возможностью наличия в зависимостях статической библиотеки без
>>>соответствующего динамического аналога (я припоминаю, что, вроде, то ли
>>>libkrb, то ли libsocks [некогда] распространялся в таком вот виде). Плюс
>>>всякие third-party, но это уже их головная боль, наверное.
>>>
>>>      
>>>
>>другими словами, даже деление на devel и devel-static с последующей 
>>неустановкой *-static для  сборки программы с динамической линковкой в 
>>общем случае некорректно?
>>    
>>
>
>В том случае, о котором идёт речь в 7.2, некорректно.
>Правда, у нас в Сизифе таких всего 2:
>glibc-devel (libc_nonshared.a и *crt*.o) и gcc (*crt*.o).
>И надеюсь, что не будет.
>
>  
>
>>>7.3. Во-третьих, кроме dependency libs, содержимое .la-файла (конкретно,
>>>имя библиотеки) используется libtool'ом для обеспечения корректной работы
>>>с ltdl-модулями (см. autobook)
>>>
>>>      
>>>
>>Предыдущее предположение и здесь в силе?
>>    
>>
>
>Нет.  Во время динамической загрузки можно нормально загрузить только
>динамические модули.
>  
>

Я так понял, что если на этапе сборки не были доступны *.la, то во время 
запуска программы хоть эти *la и не участвуют, но проблемы заложенные 
недостатком информации при сборке остаются.

>  
>
>>>8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5.
>>>libtool подправлен таким образом, чтобы при динамической сборке на линуксе
>>>список dependency_libs не раскрывался вовсе (при статической все 
>>>по-прежнему).
>>>Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере,
>>>вроде бы, решает все остальные.
>>>
>>>      
>>>
>>А почему нельзя на этапе сборки просто ограничить выбор пакетов 
>>правильными зависимостями в спеке? Разве это не ограничит выбор 
>>dependency_libs?
>>    
>>
>
>Вы предлагаете ликвидировать find-requires и перейти на указание
>зависимостей собранных пакетов вручную?
>  
>
Ни разу. Просто в спецслучаях указывать из нескольких альтенатив 
(libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие конкурентов.
По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь есть?

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

[Dmitry V. Levin]

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

On Sun, Jan 11, 2004 at 07:57:34PM +0300, Алексей Любимов wrote:
> Dmitry V. Levin пишет:
> >On Sun, Jan 11, 2004 at 05:44:30PM +0300, Алексей Любимов wrote:
> > 
> >>>5. После обнаружения .la-файла, оригинальный (неправленный Альтом) 
> >>>libtool
> >>>использует информацию из dependency_libs для рекурсивного разворачивания
> >>>цепочки зависимостей библиотек до самого низа. При этом очевидно, что
> >>>при некоторых условиях возможна ситуация, когда одновременно линкеру
> >>>передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)).
> >>>
> >>Вопрос
> >>а если в системе стоят только  libdb4.0 и libdb4.1, libdb4.1-devel (со 
> >>статиком)
> >>будет подхвачена libdb4.0?
> >
> >Во время сборки или во время запуска?
> >
> 1 момент. - Во время сборки.
> При отсутствии -devel, разве может программа прилинковаться к библиотеке.

Теоретически - да, например,
gcc sample.c /lib/libdb-4.1.so -o sample

На практике так обычно не линкуются.

> >Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L
> >- с библиотекой libdb4.0, то во время запуска программы A в памяти
> >окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны.
> 
> То, что  вся цепочка слинкованных программ должна быть связана с одной 
> версией libdb4.1 естественно.
> Но проблема то поднималась другая. Лишние связи, когда при сборке 
> программ могут быть подсунуты случайные версии и даже вперемешку. Разве 
> не так?

Разве это другая задача?

Как вы сможете отличить случайную линковку от неслучайной?
Есть, конечно, некоторые приёмы, которые позволяют определить,
используется ли данной программой/библиотекой данная библиотека напрямую.

Проще и эффективнее поступить так:
если есть источник случайных зависимостей, то его надо закрыть.

> Рекурсивно разворачивать во время сборки все связи и завершать сборку 
> при конфликте версий через другие линкуемые библиотеки имхо совсем 
> другая задача. не так?

Это не задача, это приём, который имеет смысл применить, хотя он и не
может выявить всё, например, проблемы, возникающие при динамической
загрузке модулей.

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

> >>>Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными
> >>>Последствиями" для базы rpm, в частности.
> >>>
> >>А bte зачем делали?
> >
> >О чём это вы?  BTE - это миф.
> >Если программа A из предыдущего примера не используется во время сборки
> >других пакетов, то выявить её неработоспособность путём пересборки Сизифа
> >не удастся.
> >
> Это совсем из другой оперы. Предлагается то курочить aclocal, то есть 
> влиять исключительно на процесс сборки. А какой тогда в этом смысл, если 
> программа в сборке просто не участвует?

Кто предлагает курочить aclocal, какая программа не участвует в сборке?
Ничего не понял.

> Я так понял, что если на этапе сборки не были доступны *.la, то во время 
> запуска программы хоть эти *la и не участвуют, но проблемы заложенные 
> недостатком информации при сборке остаются.

Я понимаю ситуацию ровно наоборот.
Если сборка (динамическая) идёт без .la-файлов, то никакой нехватки
информации нет, ни во время сборки, ни во время работы.

Фактически, как уже было сказано неоднократно, библиотечные .la-файлы
бывают нужны для статической сборки, а модульныке - для динамической
загрузки модулей средствами ltdl.

> >>>8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5.
> >>>libtool подправлен таким образом, чтобы при динамической сборке на 
> >>>линуксе
> >>>список dependency_libs не раскрывался вовсе (при статической все 
> >>>по-прежнему).
> >>>Это решение, впрочем, не закрывает проблему 7.2, но, по крайней мере,
> >>>вроде бы, решает все остальные.
> >>>
> >>А почему нельзя на этапе сборки просто ограничить выбор пакетов 
> >>правильными зависимостями в спеке? Разве это не ограничит выбор 
> >>dependency_libs?
> >
> >Вы предлагаете ликвидировать find-requires и перейти на указание
> >зависимостей собранных пакетов вручную?
> >
> Ни разу. Просто в спецслучаях указывать из нескольких альтенатив 
> (libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие конкурентов.

Что такое спецслучаи и кто будет их отлавливать?
Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно
разные libdb4.X?  А если это невозможно?

> По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь есть?

Есть и будет появляться новое всегда, когда у библиотеки меняется soname.


-- 
ldv

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

[devel] Re: .a vs .so

[Mikhail Zabaluev]

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

Привет,

Алексей, спасибо за то, что нашли время на просвещение :)

Я согласен, что совсем ломать возможность статической сборки не стоит,
даже если все пакеты для этого нужно пересобирать с --enable static.

On Sun, Jan 11, 2004 at 08:23:29AM +0600, Alexey Morozov wrote:
>
> 5. После обнаружения .la-файла, оригинальный (неправленный Альтом) libtool
> использует информацию из dependency_libs для рекурсивного разворачивания
> цепочки зависимостей библиотек до самого низа. При этом очевидно, что
> при некоторых условиях возможна ситуация, когда одновременно линкеру
> передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)).
> 
> Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными
> Последствиями" для базы rpm, в частности.

Замечу, что в варианте статической линковки от Ужасных Последствий
избавиться невозможно, не изменив набора требуемых для сборки
библиотек (что почти наверняка потребует изменения кода).

> 7.2. Во-вторых, вне зависимости от характера линковки, нам, строго говоря,
> _необходима_ информация, записанная в  dependency_libs. Необходимость
> этой информации обусловлена [достаточно гипотетической, впрочем]
> возможностью наличия в зависимостях статической библиотеки без
> соответствующего динамического аналога (я припоминаю, что, вроде, то ли
> libkrb, то ли libsocks [некогда] распространялся в таком вот виде).

Надеюсь, подобные случаи (наличие _только_ статической библиотеки, для
чего-то собранной libtool) уже не имеют места быть.

> 8. Предложено (Дмитрием же) альтернативное решение для проблемы из п. 5.
> libtool подправлен таким образом, чтобы при динамической сборке на линуксе
> список dependency_libs не раскрывался вовсе (при статической все
> по-прежнему).

По зрелом размышлении, мне нравится этот вариант.
Хотелось бы, чтобы при динамической линковке libtool при указании -lsome
"не замечал" наличия соответствующего .la-файла, т.е. результирующая
команда была бы одинаковой как при наличии .la, так и при его отсутствии.
Явное же указание .la-файлов в параметрах libtool я по-прежнему
считаю порочной практикой.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org

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

[devel] Re: .a vs .so

[Mikhail Zabaluev]

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

Hello Alexey,

On Sun, Jan 11, 2004 at 08:49:42AM +0600, Alexey Morozov wrote:
>
> При использовании libtoolize необходимо использовать соответствующие
> версии libtool-макросов.
> 
> В принципе, конечно, можно сказать, что сейчас в природе (в пакетах)
> существуют либо libtool-1.4, либо libtool-1.5.
> 
> Соответственно, можно говорить не libbtolize ..., а libtoolize-<version>,
> в зависимости от версии libtool, используемой данным пакетом (проверять
> по VERSION в ltmain.sh или serial в соответствующем макросе).

Насколько я понимаю, %set_libtool_version даёт именно такой эффект.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org

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

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

[Alexey Lubimov]

Dmitry V. Levin пишет:
> On Sun, Jan 11, 2004 at 07:57:34PM +0300, Алексей Любимов wrote:
> 
>>Dmitry V. Levin пишет:
>>
>>>On Sun, Jan 11, 2004 at 05:44:30PM +0300, Алексей Любимов wrote:
>>>
>>>
>>>>>5. После обнаружения .la-файла, оригинальный (неправленный Альтом) 
>>>>>libtool
>>>>>использует информацию из dependency_libs для рекурсивного разворачивания
>>>>>цепочки зависимостей библиотек до самого низа. При этом очевидно, что
>>>>>при некоторых условиях возможна ситуация, когда одновременно линкеру
>>>>>передаются две версии одной и той же библиотеки (н-р, libdb4.x :-)).
>>>>>
>>>>
>>>>Вопрос
>>>>а если в системе стоят только  libdb4.0 и libdb4.1, libdb4.1-devel (со 
>>>>статиком)
>>>>будет подхвачена libdb4.0?
>>>
>>>Во время сборки или во время запуска?
>>>
>>
>>1 момент. - Во время сборки.
>>При отсутствии -devel, разве может программа прилинковаться к библиотеке.
> 
> 
> Теоретически - да, например,
> gcc sample.c /lib/libdb-4.1.so -o sample

Это да. Только по моему перед библиотекой ключик -lm нужен.

> 
> На практике так обычно не линкуются.

По моему так линкуют только личные библиотеки из своего же состава и то 
нечасто.

> 
> 
>>>Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека L
>>>- с библиотекой libdb4.0, то во время запуска программы A в памяти
>>>окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны.
>>
>>То, что  вся цепочка слинкованных программ должна быть связана с одной 
>>версией libdb4.1 естественно.
>>Но проблема то поднималась другая. Лишние связи, когда при сборке 
>>программ могут быть подсунуты случайные версии и даже вперемешку. Разве 
>>не так?
> 
> 
> Разве это другая задача?

Если речь идет именно о сборке программ в отдельном окружении без 
конкурирующих пакетов - да.

В этом случае, есть "дефолтная" libdb4.0 и есть "несовместимая с ней 
альтернатива" libdb4.1
Программы собираются с libdb4.1
Если программа требует именно libdb4-compat4.0, то она собирается с ним 
и помечается, как libdb4-incompatible (на самом деле само по себе 
buidrequires на libdb4-compat4.0 и будет этим признаком).

При операции релиза (типа sandcl endpocket sisyphus) репозитария  можно 
хоть полдня ползать по репозитарию скриптами, раскрывая цепочки 
зависимостей (buildrequires - они железные и проверены в bte) пакетов и 
проверяя получившийся ряд на смешивание в них запрещеных сочетаний libdb.

> 
> Как вы сможете отличить случайную линковку от неслучайной?

Никак. Это как в случае с мотоциклами. Сначала удаляют "лишний метал" со 
ступицы, а потом теряют тормоза от перегрева.

Чтобы определить случайность линковки в общем случае, надо 
протестировать программу по полной программе. Имхо, сизиф страдает от 
таких "оптимизаций" поболее, чем от их отсутствия.

У программ есть авторы и они обычно пишут список зависимостей. Далее 
второе (расширяющее) приближение - сборка. На этом все начные методы 
заканчиваются иначинается либо гадание либо тупая ручная статистика 
учета возникших от оптимизации проблем.

Есть БТЕ. Вот пусть он и отсекает 100% лишнее. Остальное в сизифе просто 
не реализуемо в принципе.

> Есть, конечно, некоторые приёмы, которые позволяют определить,
> используется ли данной программой/библиотекой данная библиотека напрямую.

ldd?
имхо не слишком надежно.
> 
> Проще и эффективнее поступить так:
> если есть источник случайных зависимостей, то его надо закрыть.

ага. только не уничтожать при этом пакеты. а выборочно загружать в бте.

> 
> 
>>Рекурсивно разворачивать во время сборки все связи и завершать сборку 
>>при конфликте версий через другие линкуемые библиотеки имхо совсем 
>>другая задача. не так?
> 
> 
> Это не задача, это приём, который имеет смысл применить, хотя он и не
> может выявить всё, например, проблемы, возникающие при динамической
> загрузке модулей.
> 
> Предложите, как лучше оформить интерфейс: как описать множество
> конфликтующих библиотек (который будет меняться), как включать/выключать
> эту проверку при сборке того или иного пакета.

Я вижу это таким образом.

Должна быть практически не меняющаяся по именам умолчальная среда с 
одним претендентом по каждой альтернативе.
один gcc, glibc, libpng, libdb4 etc

Альтернативы должны имет звания gcc-compat2.96 glibc-compat2.3 
libng-compat2 libdb5-compat0 etc

Замечу, что основные имена являются скользящими. То есть libpng когда то 
было версии 2, а потом без изменения имени становится версии3, а вот 
-compat уже ссылаются на определенную версию и заморожены в таком 
состоянии.

пакеты в нормальном состоянии должны требовать в BuildRequires  gcc, 
glibc, libpng, libdb4.

Если пакет перестает собираться с новой версией и начинает требовать 
-compat, то в BuildRequires вручную ставится зависимость на конкретный 
compat.

Зависимость на -compat и является признаком замороженного на версии пакета.

Пишуться правила типа libdb conflicts libdb-compat

При пересборке факт смешанного использования библиотек через третью 
программ не ловится. Его даже и ловить не надо.

После пересборки репозитария, по нему запускается скрипт проверки, 
рекурсивно разворачивает зависимости и по правилам ловит факт смешивания 
конфоиктующих альтернатив. После этого майнтейнеры решают, что делать. 
То ли выбросить что либо из репозитария, то ли пересобрать по другому.


> 
>>>>>Это, как справедливо отметил Дмитрий Левин, чревато всякими "Ужасными
>>>>>Последствиями" для базы rpm, в частности.
>>>>>
>>>>
>>>>А bte зачем делали?
>>>
>>>О чём это вы?  BTE - это миф.
>>>Если программа A из предыдущего примера не используется во время сборки
>>>других пакетов, то выявить её неработоспособность путём пересборки Сизифа
>>>не удастся.
>>>
>>
>>Это совсем из другой оперы. Предлагается то курочить aclocal, то есть 
>>влиять исключительно на процесс сборки. А какой тогда в этом смысл, если 
>>программа в сборке просто не участвует?
> 
> 
> Кто предлагает курочить aclocal, какая программа не участвует в сборке?
> Ничего не понял.

модифицированный libtoolize Морозов предложил запускать вместо aclocal.

при сборке может отсутствовать та, третья программа, через которую 
библиотеки и конфликтуют.

Вот эта, которая L:
--------------
 >>>Если программа A была собрана с библиотекой L и с libdb4.1, а 
библиотека L
 >>>- с библиотекой libdb4.0, то во время запуска программы A в памяти
 >>>окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны.
 >>
--------------


> 
> 
>>Я так понял, что если на этапе сборки не были доступны *.la, то во время 
>>запуска программы хоть эти *la и не участвуют, но проблемы заложенные 
>>недостатком информации при сборке остаются.
> 
> 
> Я понимаю ситуацию ровно наоборот.
> Если сборка (динамическая) идёт без .la-файлов, то никакой нехватки
> информации нет, ни во время сборки, ни во время работы.
> 
> Фактически, как уже было сказано неоднократно, библиотечные .la-файлы
> бывают нужны для статической сборки, а модульныке - для динамической
> загрузки модулей средствами ltdl.

Да пока что вы противоречите друг другу с Морозовым, а я просто  не 
знаю, кто из вас прав :(


>>Ни разу. Просто в спецслучаях указывать из нескольких альтенатив 
>>(libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие конкурентов.
> 
> 
> Что такое спецслучаи и кто будет их отлавливать?

майнтейнер. прога то либо не будет собираться, либо работать.


> Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно
> разные libdb4.X?  А если это невозможно?

В бте?
такие случаи автоматом не решаются. Придется собирать консилиум 
майнтейнеров и решать, кого убрать. Как сегодня и происходит.


>>По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь есть?
> 
> 
> Есть и будет появляться новое всегда, когда у библиотеки меняется soname.

Не так. Это когда библиотеки обновляюти вместе с тем под другим именем 
оставляют старые версии. Если библиотеки просто обновляют, то либо прога 
собирается с ней, либо нет, но левых зависимостей все равно не возникает.

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

[Dmitry V. Levin]

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

On Mon, Jan 12, 2004 at 01:21:26AM +0300, Alexey Lubimov wrote:
> Dmitry V. Levin пишет:
> >On Sun, Jan 11, 2004 at 07:57:34PM +0300, Алексей Любимов wrote:
> >>Dmitry V. Levin пишет:
> >>>On Sun, Jan 11, 2004 at 05:44:30PM +0300, Алексей Любимов wrote:
[...]
> >>>Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека 
> >>>L
> >>>- с библиотекой libdb4.0, то во время запуска программы A в памяти
> >>>окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны.
> >>
> >>То, что  вся цепочка слинкованных программ должна быть связана с одной 
> >>версией libdb4.1 естественно.
> >>Но проблема то поднималась другая. Лишние связи, когда при сборке 
> >>программ могут быть подсунуты случайные версии и даже вперемешку. Разве 
> >>не так?
> >
> >Разве это другая задача?
> 
> Если речь идет именно о сборке программ в отдельном окружении без 
> конкурирующих пакетов - да.
> 
> В этом случае, есть "дефолтная" libdb4.0 и есть "несовместимая с ней 
> альтернатива" libdb4.1
> Программы собираются с libdb4.1
> Если программа требует именно libdb4-compat4.0, то она собирается с ним 
> и помечается, как libdb4-incompatible (на самом деле само по себе 
> buidrequires на libdb4-compat4.0 и будет этим признаком).
> 
> При операции релиза (типа sandcl endpocket sisyphus) репозитария  можно 
> хоть полдня ползать по репозитарию скриптами, раскрывая цепочки 
> зависимостей (buildrequires - они железные и проверены в bte) пакетов и 
> проверяя получившийся ряд на смешивание в них запрещеных сочетаний libdb.

Это всё замечательно и можно применить прямо сейчас к текущему Сизифу, но
в результате этой технически непростой работы можно будет лишь
констатировать несовместимость.  Это само по себе хорошо, но работы по
исправлению пакетов при этом меньше не станет.

Собственно говоря, это ответ на другой вопрос.

> >Как вы сможете отличить случайную линковку от неслучайной?
> 
> Никак. Это как в случае с мотоциклами. Сначала удаляют "лишний метал" со 
> ступицы, а потом теряют тормоза от перегрева.
> 
> Чтобы определить случайность линковки в общем случае, надо 
> протестировать программу по полной программе. Имхо, сизиф страдает от 
> таких "оптимизаций" поболее, чем от их отсутствия.

Это как (протестировать программу по полной программе)?

> У программ есть авторы и они обычно пишут список зависимостей. Далее 
> второе (расширяющее) приближение - сборка. На этом все начные методы 
> заканчиваются иначинается либо гадание либо тупая ручная статистика 
> учета возникших от оптимизации проблем.

Это очень оптимистичная оценка maintainer'ов, которые на самом деле очень
занятые и ленивые люди.  Не для всех пересобрать пакет раз в месяц
является выполнимой задачей.  Это надо иметь в виду.
> 
> Есть БТЕ. Вот пусть он и отсекает 100% лишнее. Остальное в сизифе просто 
> не реализуемо в принципе.

Значит, надо искать другие приёмы.

> >Есть, конечно, некоторые приёмы, которые позволяют определить,
> >используется ли данной программой/библиотекой данная библиотека напрямую.
> 
> ldd?
> имхо не слишком надежно.

Конечно, это всего лишь warning, т.е. hint, если хотите.

> >>Рекурсивно разворачивать во время сборки все связи и завершать сборку 
> >>при конфликте версий через другие линкуемые библиотеки имхо совсем 
> >>другая задача. не так?
> >
> >Это не задача, это приём, который имеет смысл применить, хотя он и не
> >может выявить всё, например, проблемы, возникающие при динамической
> >загрузке модулей.
> >
> >Предложите, как лучше оформить интерфейс: как описать множество
> >конфликтующих библиотек (которое будет меняться), как включать/выключать
> >эту проверку при сборке того или иного пакета.
> 
> Я вижу это таким образом.
> 
> Должна быть практически не меняющаяся по именам умолчальная среда с 
> одним претендентом по каждой альтернативе.
> один gcc, glibc, libpng, libdb4 etc

Я вообще-то не об этом спрашивал.

> Альтернативы должны имет звания gcc-compat2.96 glibc-compat2.3 
> libng-compat2 libdb5-compat0 etc
> 
> Замечу, что основные имена являются скользящими. То есть libpng когда то 
> было версии 2, а потом без изменения имени становится версии3, а вот 
> -compat уже ссылаются на определенную версию и заморожены в таком 
> состоянии.
> 
> пакеты в нормальном состоянии должны требовать в BuildRequires  gcc, 
> glibc, libpng, libdb4.
> 
> Если пакет перестает собираться с новой версией и начинает требовать 
> -compat, то в BuildRequires вручную ставится зависимость на конкретный 
> compat.
> 
> Зависимость на -compat и является признаком замороженного на версии пакета.

Если опустить этот -compat, то именно так сейчас и происходит в Сизифе.

> Пишуться правила типа libdb conflicts libdb-compat
> 
> При пересборке факт смешанного использования библиотек через третью 
> программ не ловится. Его даже и ловить не надо.
> 
> После пересборки репозитария, по нему запускается скрипт проверки, 
> рекурсивно разворачивает зависимости и по правилам ловит факт смешивания 
> конфоиктующих альтернатив. После этого майнтейнеры решают, что делать. 
> То ли выбросить что либо из репозитария, то ли пересобрать по другому.

Можно и так ловить.

Но исправлять-то придётся, и не факт, что это будет просто сделать, если
одна из зависимостей наведённая.

> >>Я так понял, что если на этапе сборки не были доступны *.la, то во время 
> >>запуска программы хоть эти *la и не участвуют, но проблемы заложенные 
> >>недостатком информации при сборке остаются.
> >
> >
> >Я понимаю ситуацию ровно наоборот.
> >Если сборка (динамическая) идёт без .la-файлов, то никакой нехватки
> >информации нет, ни во время сборки, ни во время работы.
> >
> >Фактически, как уже было сказано неоднократно, библиотечные .la-файлы
> >бывают нужны для статической сборки, а модульные - для динамической
> >загрузки модулей средствами ltdl.
> 
> Да пока что вы противоречите друг другу с Морозовым, а я просто не 
> знаю, кто из вас прав :(

Противоречие только в предлагаемых подходах к разруливанию.  Во всём
остальном - полное взаимопонимание. :)

> >>Ни разу. Просто в спецслучаях указывать из нескольких альтенатив 
> >>(libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие 
> >>конкурентов.
> >
> >Что такое спецслучаи и кто будет их отлавливать?
> 
> майнтейнер. прога то либо не будет собираться, либо работать.
> 
> >Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно
> >разные libdb4.X?  А если это невозможно?
> 
> В бте?
> такие случаи автоматом не решаются. Придется собирать консилиум 
> майнтейнеров и решать, кого убрать. Как сегодня и происходит.
> 
> >>По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь 
> >>есть?
> >
> >Есть и будет появляться новое всегда, когда у библиотеки меняется soname.
> 
> Не так. Это когда библиотеки обновляюти вместе с тем под другим именем 
> оставляют старые версии. Если библиотеки просто обновляют, то либо прога 
> собирается с ней, либо нет, но левых зависимостей все равно не возникает.

Если у библиотеки достаточно разных пользователей, то её нельзя "просто"
обновить, не сохранив прежнюю альтернативу.  Сколько времени она будет
жить, в каждом конкретном случае бывает по-разному.


-- 
ldv

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

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

[Alexey Lubimov]

Dmitry V. Levin пишет:

>>При операции релиза (типа sandcl endpocket sisyphus) репозитария  можно 
>>хоть полдня ползать по репозитарию скриптами, раскрывая цепочки 
>>зависимостей (buildrequires - они железные и проверены в bte) пакетов и 
>>проверяя получившийся ряд на смешивание в них запрещеных сочетаний libdb.
> 
> 
> Это всё замечательно и можно применить прямо сейчас к текущему Сизифу, но
> в результате этой технически непростой работы можно будет лишь
> констатировать несовместимость.  Это само по себе хорошо, но работы по
> исправлению пакетов при этом меньше не станет.

Не совсем так.
Это должна быть в большинстве своем автоматическая работа.
Кладем новую библиотеку (руками и быстро), пересобираем репозитарий 
(автомат и долго) и выясняем две цифры - количество непересобранного и 
количество собранного неправильно. Если результат приемлим (ручная 
работа по правилам головой) - второй этап - тестирование в дедалусе 
(общественность и майнтейнеры). получили подтверждение работоспособности 
- в сизиф (общественность).


> 
> Собственно говоря, это ответ на другой вопрос.
> 
> 
>>>Как вы сможете отличить случайную линковку от неслучайной?
>>
>>Никак. Это как в случае с мотоциклами. Сначала удаляют "лишний метал" со 
>>ступицы, а потом теряют тормоза от перегрева.
>>
>>Чтобы определить случайность линковки в общем случае, надо 
>>протестировать программу по полной программе. Имхо, сизиф страдает от 
>>таких "оптимизаций" поболее, чем от их отсутствия.
> 
> 
> Это как (протестировать программу по полной программе)?

Для библиотеки либо прогнать тесткейсы на все случаи ее использования 
либо протестировать все программы, ее использующие. Для программ - 
прогнать все функции и убедится, что все работает так, как 
предполагается. Таких возможностей все равно нет. Стало быть надо быть 
поскромнее в своем стремлении вмешаться в процесс сборки программы  и 
уйти с общего для всех пользователей софтины тест-пространства.


>>У программ есть авторы и они обычно пишут список зависимостей. Далее 
>>второе (расширяющее) приближение - сборка. На этом все начные методы 
>>заканчиваются иначинается либо гадание либо тупая ручная статистика 
>>учета возникших от оптимизации проблем.
> 
> 
> Это очень оптимистичная оценка maintainer'ов, которые на самом деле очень
> занятые и ленивые люди.  Не для всех пересобрать пакет раз в месяц
> является выполнимой задачей.  Это надо иметь в виду.

Я говорил про авторов, а не про майнтейнеров. Автор разбирается в том, 
что он написал и имеет фидбек поболее майнтейнера отдельно взятого 
альтлинукса.

> 
>>Есть БТЕ. Вот пусть он и отсекает 100% лишнее. Остальное в сизифе просто 
>>не реализуемо в принципе.
> 
> 
> Значит, надо искать другие приёмы.

Пока что это означает закрытие дистров от расширений и выдавливание 
самих себя на обочину. Осталось зарезать libtool с тем, чтобы вообще 
ничего несизифного не собиралось и задача бужет выполнена.

> 
> 
>>>Есть, конечно, некоторые приёмы, которые позволяют определить,
>>>используется ли данной программой/библиотекой данная библиотека напрямую.
>>
>>ldd?
>>имхо не слишком надежно.
> 
> 
> Конечно, это всего лишь warning, т.е. hint, если хотите.
> 
в логи, в логи хинты.


как и потерянные в RPM_BUILD_ROOT файлы,  а за потерянный там *.pc 
можно и error выкатить

Конечно, диагностики всегда мало. :)


>>>>Рекурсивно разворачивать во время сборки все связи и завершать сборку 
>>>>при конфликте версий через другие линкуемые библиотеки имхо совсем 
>>>>другая задача. не так?
>>>
>>>Это не задача, это приём, который имеет смысл применить, хотя он и не
>>>может выявить всё, например, проблемы, возникающие при динамической
>>>загрузке модулей.
>>>
>>>Предложите, как лучше оформить интерфейс: как описать множество
>>>конфликтующих библиотек (которое будет меняться), как включать/выключать
>>>эту проверку при сборке того или иного пакета.
>>
>>Я вижу это таким образом.
>>
>>Должна быть практически не меняющаяся по именам умолчальная среда с 
>>одним претендентом по каждой альтернативе.
>>один gcc, glibc, libpng, libdb4 etc
> 
> 
> Я вообще-то не об этом спрашивал.

Возможно. Если вы хотите сразу код, то по моему, до него еще дожить надо.


>>Альтернативы должны имет звания gcc-compat2.96 glibc-compat2.3 
>>libng-compat2 libdb5-compat0 etc
>>
>>Замечу, что основные имена являются скользящими. То есть libpng когда то 
>>было версии 2, а потом без изменения имени становится версии3, а вот 
>>-compat уже ссылаются на определенную версию и заморожены в таком 
>>состоянии.
>>
>>пакеты в нормальном состоянии должны требовать в BuildRequires  gcc, 
>>glibc, libpng, libdb4.
>>
>>Если пакет перестает собираться с новой версией и начинает требовать 
>>-compat, то в BuildRequires вручную ставится зависимость на конкретный 
>>compat.
>>
>>Зависимость на -compat и является признаком замороженного на версии пакета.
> 
> 
> Если опустить этот -compat, то именно так сейчас и происходит в Сизифе.

не совсем. Я должен в зависимостях указывать libqt3, libpng3, libdb4.1
А тут я в большинстве случаев указываю  libpng libdb4 , а подставляется 
дефолтная версия. Таким образом можно склонить большинство пакетов к 
одной версии либы и выделить действительно неработающие compat-требующие 
пакеты. Правда, не уверен, что это осуществимо...

> 
>>Пишуться правила типа libdb conflicts libdb-compat
>>
>>При пересборке факт смешанного использования библиотек через третью 
>>программ не ловится. Его даже и ловить не надо.
>>
>>После пересборки репозитария, по нему запускается скрипт проверки, 
>>рекурсивно разворачивает зависимости и по правилам ловит факт смешивания 
>>конфоиктующих альтернатив. После этого майнтейнеры решают, что делать. 
>>То ли выбросить что либо из репозитария, то ли пересобрать по другому.
> 
> 
> Можно и так ловить.

пока не ловится и тем более не ловится автоматом.

> 
> Но исправлять-то придётся, и не факт, что это будет просто сделать, если
> одна из зависимостей наведённая.

Ну так наведеных зависимостей должен быть минимум. Для того в чрут и 
загоняем.
вот, к примеру, wine ис сизифа тащит за собой пол кде.
пересборка без кде либ полностью очищает его от зависимостей на них.

> Противоречие только в предлагаемых подходах к разруливанию.  Во всём
> остальном - полное взаимопонимание. :)

ну и славно. :)

> 
> 
>>>>Ни разу. Просто в спецслучаях указывать из нескольких альтенатив 
>>>>(libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие 
>>>>конкурентов.
>>>
>>>Что такое спецслучаи и кто будет их отлавливать?

случаи, когда в репозитарии есть одновременно несколько одинаковых 
библиотек разных версий. Их даже по имени можно узнать. У них версия в 
нем сидит.

майнтейнер будет отлавливать по факту несборки или неработы с текущей 
версией библиотеки.

С этой версией не получилось - попробовать с другой. Получилось - либо 
портировать, либо так оставить, если никому это не надо.

Все как и сегодня, только диагностики больше и автоматизма.

>>
>>майнтейнер. прога то либо не будет собираться, либо работать.
>>
>>
>>>Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно
>>>разные libdb4.X?  А если это невозможно?
>>
>>В бте?
>>такие случаи автоматом не решаются. Придется собирать консилиум 
>>майнтейнеров и решать, кого убрать. Как сегодня и происходит.
>>
Да, только сегодня убирают из репозитария, а я предлагаю убирать из БТЕ. 
Для этого консилиум не нужен. Он нужен только в случае совместного 
использования либы между собой и через себя. И только между 
заинтересованными майнтейнерами. А арбитр - проверка репозитария на 
выпавшие пакеты.

>>
>>>>По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь 
>>>>есть?
>>>
>>>Есть и будет появляться новое всегда, когда у библиотеки меняется soname.
>>
>>Не так. Это когда библиотеки обновляюти вместе с тем под другим именем 
>>оставляют старые версии. Если библиотеки просто обновляют, то либо прога 
>>собирается с ней, либо нет, но левых зависимостей все равно не возникает.
> 
> 
> Если у библиотеки достаточно разных пользователей, то её нельзя "просто"
> обновить, не сохранив прежнюю альтернативу.  Сколько времени она будет
> жить, в каждом конкретном случае бывает по-разному.
> 
Ну не надо скромничать. В свое время libgnomeprint(ui) 2.0 молча 
задавили, хотя она даже не мешала версии 2.2.

glabels, помнится тогда автоматом улетела и еще несколько неплохих 
программ...

Собственно, спецслучай от количества не перестает быть спецслучаем. Если 
есть несколько версий библиотеки  - майнтейнер должен либо ничего не 
выбирать и тогда должна ставится текущая дефолтная либа, либо честно 
выбрать соответствующий -compat.

[devel] Re: .a vs .so

[Michael Shigorin]

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

On Sun, Jan 11, 2004 at 08:49:42AM +0600, Alexey Morozov wrote:
> > > "libtoolize --force".
> > Говоря за себя... и так местами используется (например, взяв из
[nasty skip]
> существуют либо libtool-1.4, либо libtool-1.5.
> Соответственно, можно говорить не libbtolize ..., а
> libtoolize-<version>, в зависимости от версии libtool,

home:~/RPM/SPECS> fgrep -r %set_libtool_version * | wc -l
      3

:)

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

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

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

[Vitaly Lipatov]

On 12 Январь 2004 03:57, Alexey Lubimov wrote:
> Ну так наведеных зависимостей должен быть минимум. Для того в
> чрут и загоняем.
> вот, к примеру, wine ис сизифа тащит за собой пол кде.
> пересборка без кде либ полностью очищает его от зависимостей
> на них.
Плохой пример :) Такого уже нет ровно месяц :)


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

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

[Алексей Любимов]

Vitaly Lipatov пишет:

>On 12 Январь 2004 03:57, Alexey Lubimov wrote:
>  
>
>>Ну так наведеных зависимостей должен быть минимум. Для того в
>>чрут и загоняем.
>>вот, к примеру, wine ис сизифа тащит за собой пол кде.
>>пересборка без кде либ полностью очищает его от зависимостей
>>на них.
>>    
>>
>Плохой пример :) Такого уже нет ровно месяц :)
>  
>
не обольщайтесь. проверял пару дней назад - все есть в полной мере. и 
сборка - октябрьская.

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

[Алексей Любимов]

Алексей Любимов пишет:

>
>
> Vitaly Lipatov пишет:
>
>> On 12 Январь 2004 03:57, Alexey Lubimov wrote:
>>  
>>
>>> Ну так наведеных зависимостей должен быть минимум. Для того в
>>> чрут и загоняем.
>>> вот, к примеру, wine ис сизифа тащит за собой пол кде.
>>> пересборка без кде либ полностью очищает его от зависимостей
>>> на них.
>>>   
>>
>> Плохой пример :) Такого уже нет ровно месяц :)
>>  
>>
> не обольщайтесь. проверял пару дней назад - все есть в полной мере. и 
> сборка - октябрьская.
>
если только я опять с зеркалом не напутал...

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

[Vitaly Lipatov]

On 13 Январь 2004 19:02, Алексей Любимов wrote:
> если только я опять с зеркалом не напутал...
Напутал, напутал :)
С середины декабря в Сизифе лежит сборка от 12 декабря...

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!