[sisyphus] libart_lgpl_2.la

[sisyphus] libart_lgpl_2.la

[Nick Fedchik]

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

[fnm@fnm konversation-0.13]$ make
make  all-recursive
make[1]: Entering directory `/home/fnm/src/konversation-0.13'
Making all in konversation
make[2]: Entering directory `/home/fnm/src/konversation-0.13/konversation'
/bin/sh ../libtool --silent --mode=link --tag=CXX g++  -Wnon-virtual-dtor 
-Wno-long-long -Wunde
...
ce_skel.o prefspageirccolorsui.o irccolorchooserui.o -lkio -lm
libtool: link: cannot find the library `/usr/lib/libart_lgpl_2.la'
make[2]: *** [konversation] Ошибка 1
make[2]: Leaving directory `/home/fnm/src/konversation-0.13/konversation'
make[1]: *** [all-recursive] Ошибка 1
make[1]: Leaving directory `/home/fnm/src/konversation-0.13'
make: *** [all] Ошибка 2

И его действительно нет:
[fnm@fnm konversation-0.13]$ ls -1 /usr/lib/libart_*
/usr/lib/libart_lgpl_2.so
/usr/lib/libart_lgpl_2.so.2
/usr/lib/libart_lgpl_2.so.2.3.16
/usr/lib/libart_lgpl.la
/usr/lib/libart_lgpl.so
/usr/lib/libart_lgpl.so.2
/usr/lib/libart_lgpl.so.2.2.0

Установлены:
[fnm@fnm konversation-0.13]$ rpm -q -a|grep libart_lgpl
libart_lgpl-2.3.16-alt2
libart_lgpl-devel-2.3.16-alt2


-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

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

Re: [sisyphus] libart_lgpl_2.la

[Alexey Morozov]

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

Читайте ченджлог пакетов. Зачем Дмитрием Левиным придумана эта полиси,
я НЕ ПОНИМАЮ. Внятного ответа в архивах списка рассылки я не нашел.
В архивах есть 
http://www.altlinux.ru/pipermail/devel/2003-November/032895.html,
но не предшествующего ему, ни последующих писем я там не нашел.

Так что, имеет смысл задать этот вопрос непосредственно Дмитрию.



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

Re: [sisyphus] *.la

[Nick Fedchik]

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

В сообщении от Пн 01 Дек 2003 15:41 Alexey Morozov написал(a):
> Читайте ченджлог пакетов. Зачем Дмитрием Левиным придумана эта полиси,
> я НЕ ПОНИМАЮ. Внятного ответа в архивах списка рассылки я не нашел.
> В архивах есть
> http://www.altlinux.ru/pipermail/devel/2003-November/032895.html,
Почитал...

> но не предшествующего ему, ни последующих писем я там не нашел.
Я тоже НЕ ПОНИМАЮ.
Я также НЕ ПОНИМАЮ, почему я не могу САМ собрать нужный мне пакет, который не 
валяется готовым в Sisyphus-е... если при этом я стараюсь ВСЕГДА установить 
библиотеку из репозитория, если она там есть.
А если она там есть, и я при этом не могу сделать сборку пакета, использующего 
libtool, то я этого НЕ ПОНИМАЮ.
Я работаю на проинсталленой ALT Sisyphus потому что мне надо на ней 
разрабатывать ПО, и меня интересуют в первую очередь новые функциональности 
относящихся к разработке пакетов.
Для этого мне совершенно не нужна рассылка devel@ ...
И если там кто-то вдруг принимает такие policy, то я тоже, как Шигорин:
"Доверяю по убывающей." :(
Сегодня мне это было не критично, но кто знает что случится завтра?
И вот только не надо напоминать про "нестабильные" репозитории и т.п...

> Так что, имеет смысл задать этот вопрос непосредственно Дмитрию.
Автора, автора! :)))

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

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

Re: [sisyphus] *.la

[Alexey Morozov]

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

On Mon, Dec 01, 2003 at 04:09:44PM +0200, Nick Fedchik wrote:
> > http://www.altlinux.ru/pipermail/devel/2003-November/032895.html,
> Почитал...
Ну, тут еще рассказывали про письмо Дмитрия в devel, но сейчас у меня
там подписки нет, а в архивах - полная фигня, как всегда :-/, привет
мэйлмэну. Поэтому, видимо, нужно просить его переотправить это письмо
в Сизиф, где его прочитает существенно бОльшее количество народу.
И потом этот народ сможет решить, как ему быть в подобной ситуации.

> Для этого мне совершенно не нужна рассылка devel@ ...
> И если там кто-то вдруг принимает такие policy, то я тоже, как Шигорин:
> "Доверяю по убывающей." :(
> Сегодня мне это было не критично, но кто знает что случится завтра?
А мне, похоже, критично уже сегодня. По крайней мере, gtkhtml3 не
единственный, кто ломается в такой ситуации.

> > Так что, имеет смысл задать этот вопрос непосредственно Дмитрию.
> Автора, автора! :)))
Ну, я ставлю его в Cc: по этой переписке...


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

Re: [sisyphus] KDE without .la (was libart_lgpl_2.la)

[Sergey V Turchin]

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

В сообщении от 1 Декабрь 2003 15:51 Nick Fedchik написал(a):

<skip/>

> ce_skel.o prefspageirccolorsui.o irccolorchooserui.o -lkio -lm
> libtool: link: cannot find the library
> `/usr/lib/libart_lgpl_2.la' make[2]: *** [konversation] Ошибка 1
> make[2]: Leaving directory
> `/home/fnm/src/konversation-0.13/konversation' make[1]: ***
> [all-recursive] Ошибка 1
> make[1]: Leaving directory `/home/fnm/src/konversation-0.13'
> make: *** [all] Ошибка 2
>
> И его действительно нет:

С KDE-шными пакетами подождите пока новые kdelibs не соберу,
новые будут работать без *.la, но для загрузки плагинов 
необходимы будут *.so в не-devel пакете

-- 
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: [sisyphus] KDE without .la (was libart_lgpl_2.la)

[Alexey Morozov]

В сообщении от Понедельник 01 Декабрь 2003 20:27 Sergey V Turchin написал(a):
> С KDE-шными пакетами подождите пока новые kdelibs не соберу,
> новые будут работать без *.la, но для загрузки плагинов
> необходимы будут *.so в не-devel пакете
Вы лучше расскажите, как с этим предлагается жить.

У меня есть libtool (сама тулза, конечно, то еще дерьмо, но, как говорится, за 
неимением горничной...) У меня есть дока на libtool, в которой ясно написано 
про wrapper scripts. У меня есть софт, который этой libtool'овой 
функциональностью пользуется. Как предлагается обходить эти грабли?

[sisyphus] Fw: [devel] I: eliminating unneeded libtool library files

[Grigory Batalov]

On Mon, 1 Dec 2003 20:22:05 +0600
Alexey Morozov <alex-altlinux@idisys.iae.nsk.su> wrote:

> On Mon, Dec 01, 2003 at 04:09:44PM +0200, Nick Fedchik wrote:
> > > http://www.altlinux.ru/pipermail/devel/2003-November/032895.html,
> > Почитал...
> Ну, тут еще рассказывали про письмо Дмитрия в devel, но сейчас у меня
> там подписки нет, а в архивах - полная фигня, как всегда :-/, привет
> мэйлмэну. Поэтому, видимо, нужно просить его переотправить это письмо
> в Сизиф, где его прочитает существенно бОльшее количество народу.

Begin forwarded message:

Date: Mon, 1 Dec 2003 02:22:11 +0300
From: "Dmitry V. Levin" <ldv@altlinux.org>
To: ALT Devel discussion list <devel@altlinux.ru>
Subject: [devel] I: eliminating unneeded libtool library files


Greetings!

Тема сегодняшней лекции - о пользе и вреде .la-файлов. :)

Как вы наверняка уже знаете (а если не знаете, то info libtool),
libtool хранит вспомогательную информацию о библиотеках, с которыми
работает, в т.н. libtool-файлах (они же .la-файлы).  Эту информацию
libtool использует в процессе изготовления и использования библиотек.

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

Тем не менее авторы libtool предлагают устанавливать эти .la-файлы.
Зачем?  Тут самое время вспомнить, что GNU libtool проектировался таким
образом, чтобы реализовать поддержку как можно большего числа операционных
систем, в том числе и тех, которые не поддерживают работу с разделяемыми
библиотеками или поддерживают её в неполной (по сравнению с GNU/Linux)
мере.
Для многих таких платформ информация о зависимостях между библиотеками
не может быть записана в самих библиотеках.  Поэтому libtool сохраняет
информацию о зависимостях в .la-файлах, сопровождающих устанавливаемые
библиотеки, и использует эту информацию при сборке других библиотек и
программ.
К сожалению, libtool никогда не имел и сейчас не содержит оптимальной
поддержки всех возможностей, которые предоставляет GNU/Linux.  Поэтому при
наличии "сопровождающих" .la-файлов в системе libtool поступает так же,
как и в других системах, а именно линкует все целевые объекты со всеми
библиотеками, от которых зависят непосредственно используемые библиотеки.
Таким образом, косвенные зависимости превращаются в прямые зависимости,
т.е. программы и библиотеки оказываются слинкованными с библиотеками,
которые они непосредственно не используют.

Наглядный и простой пример из базовой системы:
Есть apt-rpm (далее просто apt), который использует библиотеку librpm.
В свою очередь librpm (а именно librpmdb) использует библиотеку libdbX для
работы с базой данных пакетов rpm (/var/lib/rpm), причём для rpm-4.0.4
у нас X == 4.0.  Сам apt никакой libdb не использует, но благодаря
libtool'у и /usr/lib/librpm*.la он линкуется не только с librpm, но и с
libdb4.0.
Теперь представьте себе, что rpm-4.0.4 перешёл с libdb4.0 на libdb4.1.
Поскольку смены API в librpm не произошло, клиенты librpm не были
пересобраны.  В момент запуска apt'а загружаются сразу две libdb:
libdb4.0, с которой был собран apt, и libdb4.1, с которой был собран
librpm.  Хорошо ещё, что apt не пишет в базу данных rpm, так что
последняя, скорее всего, уцелеет.

Этих (и других похожих) неприятностей можно было бы избежать, если бы
можно было решить одну из двух задач:
1. Исправить libtool, чтобы он нормально поддерживал link_all_deplibs=no,
т.е. не линковал то, что не требуется.  К сожалению, решение этой задачи
ничего не даст в виду специфического дизайна GNU libtool: дело в том, что
почти каждый пакет с исходным текстом, использующим для сборки libtool,
содержит свою копию libtool, и для сборки будет использована именно эта
копия, а не системный libtool.  Для того, чтобы заменить libtool на
системный цивилизованным образом, необходимо использовать aclocal и
autoconf, что не всегда возможно.
2. Убрать все вредные .la-файлы из системы.  Для решения этой задачи
достаточно один раз пересобрать содержащие вредные .la-файлы пакеты и
проследить, чтобы они туда случайно не вернулись.

По очевидным причинам я выбрал второй вариант.
В /usr/lib/rpm/brp-cleanup пакета rpm-build >= 4.0.4-alt28 добавлен код,
который удаляет все файлы, имена которых заканчиваются на .la, из
каталогов /lib, /usr/lib и /usr/X11R6/lib.  Одновременно в пакет
sisyphus >= 0.5.4-alt1 была добавлена проверка на наличие таких файлов
в пакете.

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

На данный момент в Сизифе всего 500 бинарных пакетов, содержащих разные
.la-файлы, в том числе и те самые вредные .la-файлы, которые сопровождают
библиотеки.  Помимо них, есть ещё много .la-файлов, сопровождающих
plugin'ы.  Иногда такие .la-файлы используются для динамической загрузки
plugin'ов с помощью средств библиотеки ltdl.  Во всех остальных случаях от
них нет ни пользы, ни вреда.

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

Я прошу всех разработчиков в офисе ALT Linux незамедлительно собрать
свои пакеты из этого списка, а всех разработчиков вне офиса, кто не
может этого сделать, так же быстро написать об этом с тем, чтобы мы
могли сделать это за вас.


-- 
ldv

------->8------------
freetype2-devel
freetype-devel
gift-devel
guile14
guile16
id3lib-devel
imlib-devel
libaspell-devel
libbluez-devel
libbonobo-devel
libcdf-devel
libcurl-devel
libeel2-devel
libfaad-devel
libflac-devel
libfreetds-devel
libfribidi-devel
libgal-devel
libgii-devel
libgmp-devel
libgnome-desktop-devel
libgnome-panel-devel
libgpgme-devel
libhdf-devel
libieee1284-devel
libldap-devel
liblinc-devel
libmad-devel
libmdbtools-devel
libmetacity-devel
libmm-devel
libnessus-devel
libnetcdf-devel
libogg-devel
libopenobex-devel
libpcsclite-devel
libpilot-link-devel
librte-devel
libsasl2-devel
libSDL-devel
libsigc++1.2-devel
libsim
libsim-qt
libunixODBC-devel
libusb-devel
libxfce4util-devel
libxmms-devel
libxosd-devel
ORBit-devel
plptools-devel

Re: [sisyphus] KDE without .la (was libart_lgpl_2.la)

[Sergey V Turchin]

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

В сообщении от 1 Декабрь 2003 17:39 Alexey Morozov написал(a):
> В сообщении от Понедельник 01 Декабрь 2003 20:27 Sergey V Turchin 
написал(a):
> > С KDE-шными пакетами подождите пока новые kdelibs не соберу,
> > новые будут работать без *.la, но для загрузки плагинов
> > необходимы будут *.so в не-devel пакете
>
> Вы лучше расскажите, как с этим предлагается жить.
В KDE так же, как и раньше

> У меня есть libtool (сама тулза, конечно, то еще дерьмо, но, как
> говорится, за неимением горничной...) У меня есть дока на
> libtool, в которой ясно написано про wrapper scripts. У меня есть
> софт, который этой libtool'овой функциональностью пользуется. Как
> предлагается обходить эти грабли?
Не знаю, спросите у ldv@

-- 
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: [sisyphus] Fw: [devel] I: eliminating unneeded libtool library files

[Nick Fedchik]

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

В сообщении от Пн 01 Дек 2003 16:54 Grigory Batalov написал(a):
> Тема сегодняшней лекции - о пользе и вреде .la-файлов. :)
Возможно, конечно... 
Но, как говорится, свои проблемы - ближе к ... ;)
И я сказал (ранее), что я думаю по этому поводу, может оно и к лучшему, 
только вот не компиляется софтина... :(
Опять же процитирую Шигорина:
"Почему же тогда ты решаешь за других, не ставя их в *малейшую*
известность *заранее*?"
и
"Ты делаешь правильные вещи неправильным образом."
Ну про блондинку с рутовым паролем - понятно ;)

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

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

Re: [sisyphus] Fw: [devel] I: eliminating unneeded libtool library files

[Sergey S. Skulachenko]

On Mon, 1 Dec 2003 18:15:50 +0200
Nick Fedchik <nick@fedchik.org.ua> wrote:

> В сообщении от Пн 01 Дек 2003 16:54 Grigory Batalov написал(a):
> > Тема сегодняшней лекции - о пользе и вреде .la-файлов. :)

> Возможно, конечно... 
> Но, как говорится, свои проблемы - ближе к ... ;)
> И я сказал (ранее), что я думаю по этому поводу, может оно и к
> лучшему, только вот не компиляется софтина... :(

Ну, и хрен с ней! Не тревожьте Вы Дмитрия и не задирайте. Чем
быстрее он исправит ситуацию, тем лучше. Пусть работает. 

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

Re: [sisyphus] Fw: [devel] I: eliminating unneeded libtool library files

[Nick Fedchik]

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

В сообщении от Пн 01 Дек 2003 18:57 Sergey S. Skulachenko написал(a):

> > Но, как говорится, свои проблемы - ближе к ... ;)
> > И я сказал (ранее), что я думаю по этому поводу, может оно и к
> > лучшему, только вот не компиляется софтина... :(
> Ну, и хрен с ней! 
Абалдеть, шановный!!!
Вот это - подход!
Супер!
Зашибись!
Я в шоке! =8-[ ] Psycholellia!!!

> Не тревожьте Вы Дмитрия и не задирайте. 
А кого? Папу Римского?
Я что-то "левое" сказал? Без причины?

> Чем быстрее он исправит ситуацию, тем лучше. Пусть работает.
Согласен, не спорю! Заварил он "кашу" - молодец будет, 
если сам же и разгребёт!
Я бы может и помог бы, но вот теперь... :-/

ЗЫ: поздравляю тех, кого, с http://www.computersecurityday.org/ %-)
ЗЫ2: все решится в рабочем порядке, я надеюсь!

-- 
Best Regards, Nick Fedchik
http://www.fedchik.org.ua/

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

Re: [sisyphus] KDE without .la (was libart_lgpl_2.la)

[Dmitry V. Levin]

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

On Mon, Dec 01, 2003 at 08:39:23PM +0600, Alexey Morozov wrote:
> В сообщении от Понедельник 01 Декабрь 2003 20:27 Sergey V Turchin написал(a):
> > С KDE-шными пакетами подождите пока новые kdelibs не соберу,
> > новые будут работать без *.la, но для загрузки плагинов
> > необходимы будут *.so в не-devel пакете
> Вы лучше расскажите, как с этим предлагается жить.
> 
> У меня есть libtool (сама тулза, конечно, то еще дерьмо, но, как говорится, за 
> неимением горничной...) У меня есть дока на libtool, в которой ясно написано 
> про wrapper scripts. У меня есть софт, который этой libtool'овой 
> функциональностью пользуется. Как предлагается обходить эти грабли?

Вообще-то по окончании пересборки Сизифа от никаких граблей не
предвидится.


-- 
ldv

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

Re: [sisyphus] KDE without .la (was libart_lgpl_2.la)

[Alexey Morozov]

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

On Tue, Dec 02, 2003 at 01:03:25PM +0300, Dmitry V. Levin wrote:
> > про wrapper scripts. У меня есть софт, который этой libtool'овой 
> > функциональностью пользуется. Как предлагается обходить эти грабли?
> Вообще-то по окончании пересборки Сизифа от никаких граблей не
> предвидится.
Да? Насколько я понимаю, .la вычищаются отовсюду, да? Даже там, где
описываются модули, как, например, в libgnomeprint2-2.4.2-alt1
(проапдейчен сегодня)?

Если проведенный мной простой тест (см. например, autobook) верен, то
конструкция

lt_dlopenext("somemodule");

перестает работать, если удалить соответствующие .la-файлы. То есть,
конечно,

lt_dlopenext("somemodule.so");

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

То есть, я так понимаю, практика огульного убивания .la файлов просто
приведет к тому, что понадобится капитально патчить приложения, которым
вздумалось попользоваться плагинами (а именно, вталкивать руками в каждое
из приложений функциональность, похороненную в ltdl).

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

Итого, сухой остаток: нынешняя политика в отношении .la файлов в Сизифе
- НЕКОРРЕКТНА, т.к. напрямую противоречит документации.


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

Re: [sisyphus] Удаление .la-файлов (was KDE without .la (was libart_lgpl_2.la))

[Alexey Morozov]

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

On Wed, Dec 03, 2003 at 09:27:32PM +0600, Alexey Morozov wrote:
> On Tue, Dec 02, 2003 at 01:03:25PM +0300, Dmitry V. Levin wrote:
> > > про wrapper scripts. У меня есть софт, который этой libtool'овой 
> > > функциональностью пользуется. Как предлагается обходить эти грабли?
> > Вообще-то по окончании пересборки Сизифа от никаких граблей не
> > предвидится.
> конструкция
> 
> lt_dlopenext("somemodule");
> 
> перестает работать, если удалить соответствующие .la-файлы. То есть,
Да, еще граблю увидал: без информации о dependency_libs статическая
линковка при помощи libtool идет лесом, насколько я понимаю, да?

Кто-нибудь прокомментирует эти два письма?


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

Re: [sisyphus] .la files

[Dmitry V. Levin]

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

On Wed, Dec 03, 2003 at 09:27:32PM +0600, Alexey Morozov wrote:
> On Tue, Dec 02, 2003 at 01:03:25PM +0300, Dmitry V. Levin wrote:
> > > про wrapper scripts. У меня есть софт, который этой libtool'овой 
> > > функциональностью пользуется. Как предлагается обходить эти грабли?
> > Вообще-то по окончании пересборки Сизифа от никаких граблей не
> > предвидится.
> Да? Насколько я понимаю, .la вычищаются отовсюду, да? Даже там, где
> описываются модули, как, например, в libgnomeprint2-2.4.2-alt1
> (проапдейчен сегодня)?
> 
> Если проведенный мной простой тест (см. например, autobook) верен, то
> конструкция
> 
> lt_dlopenext("somemodule");
> 
> перестает работать, если удалить соответствующие .la-файлы. То есть,
> конечно,
> 
> lt_dlopenext("somemodule.so");
> 
> работает по-прежнему, но тогда приходится указывать точное имя (то есть,
> с префиксом somemodule_LTX_) для каждой функции, вызываемой из этого
> модуля, что несколько, э-э-э, неудобно и противоречит самой идее
> загружаемых модулей с единым интерфейсом.

Если это так, то можно пропатчить lt_dlopenext, чтобы
lt_dlopenext("somemodule");
не переставал работать.

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

Нет.

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

Почему?
Во-первых, libtool сам линкует плагины со всеми библиотеками, которые
указаны в dependency_libs.
Во-вторых, зачем линковаться с плагинами - они ведь не рассчитаны на такое
использование.

> Итого, сухой остаток: нынешняя политика в отношении .la файлов в Сизифе
> - НЕКОРРЕКТНА, т.к. напрямую противоречит документации.

Какой такой документации?


-- 
ldv

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

[sisyphus] Re: .la files

[Dmitry V. Levin]

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

On Thu, Dec 04, 2003 at 05:55:48PM +0600, Alexey Morozov wrote:
> On Wed, Dec 03, 2003 at 09:27:32PM +0600, Alexey Morozov wrote:
> > On Tue, Dec 02, 2003 at 01:03:25PM +0300, Dmitry V. Levin wrote:
> > > > про wrapper scripts. У меня есть софт, который этой libtool'овой 
> > > > функциональностью пользуется. Как предлагается обходить эти грабли?
> > > Вообще-то по окончании пересборки Сизифа от никаких граблей не
> > > предвидится.
> > конструкция
> > 
> > lt_dlopenext("somemodule");
> > 
> > перестает работать, если удалить соответствующие .la-файлы. То есть,
> Да, еще граблю увидал: без информации о dependency_libs статическая
> линковка при помощи libtool идет лесом, насколько я понимаю, да?

Это верно.
Без информации о dependency_libs статическая линковка при помощи libtool
идет лесом.


-- 
ldv

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

Re: [sisyphus] Удаление .la-файлов (was KDE without .la (was libart_lgpl_2.la))

[Sergey Vlasov]

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

On Thu, Dec 04, 2003 at 05:55:48PM +0600, Alexey Morozov wrote:
> On Wed, Dec 03, 2003 at 09:27:32PM +0600, Alexey Morozov wrote:
> > On Tue, Dec 02, 2003 at 01:03:25PM +0300, Dmitry V. Levin wrote:
> > > > про wrapper scripts. У меня есть софт, который этой libtool'овой 
> > > > функциональностью пользуется. Как предлагается обходить эти грабли?
> > > Вообще-то по окончании пересборки Сизифа от никаких граблей не
> > > предвидится.
> > конструкция
> > 
> > lt_dlopenext("somemodule");
> > 
> > перестает работать, если удалить соответствующие .la-файлы. То есть,

*.la вычищаются не отовсюду, а лишь из стандартных каталогов для библиотек
(/lib, /usr/lib, /usr/X11R6/lib).  Плагины обычно всё-таки лежат не в этих
каталогах...

> Да, еще граблю увидал: без информации о dependency_libs статическая
> линковка при помощи libtool идет лесом, насколько я понимаю, да?

А оно надо?

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

Re: [sisyphus] Удаление .la-файлов (was KDE without .la (was libart_lgpl_2.la))

[Alexey Morozov]

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

On Thu, Dec 04, 2003 at 03:29:28PM +0300, Sergey Vlasov wrote:
> *.la вычищаются не отовсюду, а лишь из стандартных каталогов для библиотек
> (/lib, /usr/lib, /usr/X11R6/lib).  Плагины обычно всё-таки лежат не в этих
> каталогах...
rpm -ql libgnomeprint2-devel-2.4.1.1-alt1 | grep .la (последний,
насколько я знаю, пакет с .la)
rpm -ql libgnomeprint2-devel-2.4.2-alt1 | grep .la (первый без оных)

Обратите внимание на поддиректорию
/usr/lib/иbgnomeprint/<version>/modules/

Типа, "перегибы на местах" и все такое.

> > Да, еще граблю увидал: без информации о dependency_libs статическая
> > линковка при помощи libtool идет лесом, насколько я понимаю, да?
> А оно надо?
Да, надо. Да, мне. Мне периодически приходится собирать полностью
статические приложения. До сих пор это часто удавалось сделать простым
добавлением ключа сборки. Теперь мне придется руками отслеживать
зависимости статических библиотек. Очень мило.

В общем, Сергей, я хочу, чтобы "Партия" (возможно, в Вашем лице) объявила:
в дистрибутивах AltLinux использование утилиты libtool для линковки
приложений не рекомендуется, уже использующие libtool приложения
изменены уникальным для AltLinux способом, так что при неполадках
обращаться к автору бессмысленно.

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


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

Re: [sisyphus] Re: .la files

[Alexey Morozov]

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

On Thu, Dec 04, 2003 at 03:12:42PM +0300, Dmitry V. Levin wrote:
> > Да, еще граблю увидал: без информации о dependency_libs статическая
> > линковка при помощи libtool идет лесом, насколько я понимаю, да?
> Это верно.
> Без информации о dependency_libs статическая линковка при помощи libtool
> идет лесом.
Спасибо за прямой и честный ответ.
На самом деле, спасибо, без дураков.


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

Re: [sisyphus] .la files

[Alexey Morozov]

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

On Thu, Dec 04, 2003 at 03:10:58PM +0300, Dmitry V. Levin wrote:
> > Если проведенный мной простой тест (см. например, autobook) верен, то
> > конструкция
> > 
> > lt_dlopenext("somemodule");
> > 
> > перестает работать, если удалить соответствующие .la-файлы. То есть,
> > конечно,
> > 
> > lt_dlopenext("somemodule.so");
> > 
> > работает по-прежнему, но тогда приходится указывать точное имя (то есть,
> > с префиксом somemodule_LTX_) для каждой функции, вызываемой из этого
> > модуля, что несколько, э-э-э, неудобно и противоречит самой идее
> > загружаемых модулей с единым интерфейсом.
> 
> Если это так, то можно пропатчить lt_dlopenext, чтобы
> lt_dlopenext("somemodule");
> не переставал работать.
Вообще, мне кажется, что на этом пути нас ждут вилы почище тех, которые
пытаемся убрать (из-за необходимости догадываться об имени библиотеки,
которую предлагается грузить: это ведь не только, и не столько somemodule.so,
сколько somemodule.so.<version> или вообще фиг знает что еще можно придумать,
- не зря же library_names придуман).

Кто, кстати, придумал класть .la в -devel пакеты? Для модулей это точно
некорректно (а, вообще говоря, некорректно и для просто библиотек, но
с просто библиотеками есть сложность, связанная с возможностью
сосуществования нескольких версий, которую .la-подход никак не учитывает)

> > То есть, я так понимаю, практика огульного убивания .la файлов просто
> > приведет к тому, что понадобится капитально патчить приложения, которым
> > вздумалось попользоваться плагинами (а именно, вталкивать руками в каждое
> > из приложений функциональность, похороненную в ltdl).
> Нет.
Именно так. Так как в составе пакетов идут ltdl.* и ltmain.sh от libtool
_разных_ версий, то автоматического патча на этот повод не придумаешь.
Поэтому придется либо рассчитывать на то, что "повезет" (а патч будет
немаленький в свете сказанного выше), либо тщательно глядеть в каждую
версию каждого пакета, который захотел ltdl.

> > чревата, т.к. очень часто плагины линкуются к материнской библиотеке
> > (н-р, как те же самые плагины из libgnomeprint2), причем, линкуются они,
> > опять-таки, через материнский .la-файл. Потом если кому-нибудь приспичит
> > жестко прилинковаться к данному плагину (идея вообще плохая, но мало
> > ли), то этот кто-то будет пренеприятно удивлен незамкнутостью
> > дистрибутивных пакетов.
> 
> Почему?
> Во-первых, libtool сам линкует плагины со всеми библиотеками, которые
> указаны в dependency_libs.
Хех. В dependency_libs указана /usr/lib/libMotherlib.la :-). Можете
проверить (н-р, в модулях того же libgnomeprint2). 


> Во-вторых, зачем линковаться с плагинами - они ведь не рассчитаны на такое
> использование.
Не рассчитаны кем? Автором? А [мне] не забить на то, что он рассчитывал, а
на что - нет. У нас же таки опенсорс, а не корпорация Сони с ее шифрованными
CD-дисками. На то он и линукс/эльф, чтобы иметь возможность хотеть странного.
Собственно, только эта возможность и окупает в моих глазах некоторые
неудобства в использовании линукса в сравнении с некоторой другой
операционной системой.

> > Итого, сухой остаток: нынешняя политика в отношении .la файлов в Сизифе
> > - НЕКОРРЕКТНА, т.к. напрямую противоречит документации.
> Какой такой документации?
На libtool. И libltdl в ее составе. Могу начать сыпать цитатами, если охота.
Можно, конечно, и документацию изменить до неузнаваемости, да только
это будет "уже не Джонни" (C).

Впрочем, кажется, выход есть. Как всегда, в дебиане :-)). Правда, 
это все еще проверять надо будет, насколько это выход...


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

Re: [sisyphus] Re: .la files

[Dmitry V. Levin]

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

On Fri, Dec 05, 2003 at 01:27:54AM +0600, Alexey Morozov wrote:
> On Thu, Dec 04, 2003 at 03:12:42PM +0300, Dmitry V. Levin wrote:
> > > Да, еще граблю увидал: без информации о dependency_libs статическая
> > > линковка при помощи libtool идет лесом, насколько я понимаю, да?
> > Это верно.
> > Без информации о dependency_libs статическая линковка при помощи libtool
> > идет лесом.
> Спасибо за прямой и честный ответ.
> На самом деле, спасибо, без дураков.

Если говорить более точно, то для статической линковки при помощи libtool
любой статической библиотеки с зависимостями нужна информация об этих
зависимостях, которая в как раз в .la-файле и продублирована (оригинал
находится в .so-файле, а в .a-файле её нет).


-- 
ldv

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

Re: [sisyphus] Re: .la files

[vserge]

Добрый день


Вы написали "Dmitry V. Levin" <ldv@altlinux.org> Fri, 5 Dec 2003 13:22:01
+0300:

> On Fri, Dec 05, 2003 at 01:27:54AM +0600, Alexey Morozov wrote:
> > On Thu, Dec 04, 2003 at 03:12:42PM +0300, Dmitry V. Levin wrote:
> > > > Да, еще граблю увидал: без информации о dependency_libs статическая
> > > > линковка при помощи libtool идет лесом, насколько я понимаю, да?
> > > Это верно.
> > > Без информации о dependency_libs статическая линковка при помощи libtool
> > > идет лесом.
> > Спасибо за прямой и честный ответ.
> > На самом деле, спасибо, без дураков.
> 
> Если говорить более точно, то для статической линковки при помощи libtool
> любой статической библиотеки с зависимостями нужна информация об этих
> зависимостях, которая в как раз в .la-файле и продублирована (оригинал
> находится в .so-файле, а в .a-файле её нет).
И что в этом случае делать с плагинами???

я спашиваю так как начал пересобирать openldap??

Re: [sisyphus] .la files

[Dmitry V. Levin]

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

On Fri, Dec 05, 2003 at 07:28:31AM +0600, Alexey Morozov wrote:
> On Thu, Dec 04, 2003 at 03:10:58PM +0300, Dmitry V. Levin wrote:
> > > Если проведенный мной простой тест (см. например, autobook) верен, то
> > > конструкция
> > > 
> > > lt_dlopenext("somemodule");
> > > 
> > > перестает работать, если удалить соответствующие .la-файлы. То есть,
> > > конечно,
> > > 
> > > lt_dlopenext("somemodule.so");
> > > 
> > > работает по-прежнему, но тогда приходится указывать точное имя (то есть,
> > > с префиксом somemodule_LTX_) для каждой функции, вызываемой из этого
> > > модуля, что несколько, э-э-э, неудобно и противоречит самой идее
> > > загружаемых модулей с единым интерфейсом.
> > 
> > Если это так, то можно пропатчить lt_dlopenext, чтобы
> > lt_dlopenext("somemodule");
> > не переставал работать.
> Вообще, мне кажется, что на этом пути нас ждут вилы почище тех, которые
> пытаемся убрать (из-за необходимости догадываться об имени библиотеки,
> которую предлагается грузить: это ведь не только, и не столько somemodule.so,
> сколько somemodule.so.<version> или вообще фиг знает что еще можно придумать,
> - не зря же library_names придуман).

Тем, кому нужно использовать ltdl и library_names, придётся оставить
.la-файлы.  А в простых случаях оно должно работать as is.

> Кто, кстати, придумал класть .la в -devel пакеты? Для модулей это точно
> некорректно (а, вообще говоря, некорректно и для просто библиотек, но
> с просто библиотеками есть сложность, связанная с возможностью
> сосуществования нескольких версий, которую .la-подход никак не учитывает)

Отец Всех Дистрибутивов?

> > > То есть, я так понимаю, практика огульного убивания .la файлов просто
> > > приведет к тому, что понадобится капитально патчить приложения, которым
> > > вздумалось попользоваться плагинами (а именно, вталкивать руками в каждое
> > > из приложений функциональность, похороненную в ltdl).
> > Нет.
> Именно так. Так как в составе пакетов идут ltdl.* и ltmain.sh от libtool
> _разных_ версий, то автоматического патча на этот повод не придумаешь.

А "libtoolize --ltdl"?

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

Это слишком пессимистичный прогноз.

> > > чревата, т.к. очень часто плагины линкуются к материнской библиотеке
> > > (н-р, как те же самые плагины из libgnomeprint2), причем, линкуются они,
> > > опять-таки, через материнский .la-файл. Потом если кому-нибудь приспичит
> > > жестко прилинковаться к данному плагину (идея вообще плохая, но мало
> > > ли), то этот кто-то будет пренеприятно удивлен незамкнутостью
> > > дистрибутивных пакетов.
> > 
> > Почему?
> > Во-первых, libtool сам линкует плагины со всеми библиотеками, которые
> > указаны в dependency_libs.
> Хех. В dependency_libs указана /usr/lib/libMotherlib.la :-). Можете
> проверить (н-р, в модулях того же libgnomeprint2). 

Но ведь модули того же libgnomeprint2 наверняка слинкованы с -lMotherlib?

> > Во-вторых, зачем линковаться с плагинами - они ведь не рассчитаны на такое
> > использование.
> Не рассчитаны кем? Автором? А [мне] не забить на то, что он рассчитывал, а
> на что - нет. У нас же таки опенсорс, а не корпорация Сони с ее шифрованными
> CD-дисками. На то он и линукс/эльф, чтобы иметь возможность хотеть странного.

Если автор не предусмотрел возможность линковаться с плагинами, то вполне
естественно, что придётся патчить как минимум makefile'ы.

> Собственно, только эта возможность и окупает в моих глазах некоторые
> неудобства в использовании линукса в сравнении с некоторой другой
> операционной системой.
> 
> > > Итого, сухой остаток: нынешняя политика в отношении .la файлов в Сизифе
> > > - НЕКОРРЕКТНА, т.к. напрямую противоречит документации.
> > Какой такой документации?
> На libtool. И libltdl в ее составе. Могу начать сыпать цитатами, если охота.
> Можно, конечно, и документацию изменить до неузнаваемости, да только
> это будет "уже не Джонни" (C).

Я бы изменил и документацию.


-- 
ldv

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

Re: [sisyphus] Re: .la files

[Dmitry V. Levin]

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

On Fri, Dec 05, 2003 at 01:32:11PM +0300, vserge wrote:
> > Если говорить более точно, то для статической линковки при помощи libtool
> > любой статической библиотеки с зависимостями нужна информация об этих
> > зависимостях, которая в как раз в .la-файле и продублирована (оригинал
> > находится в .so-файле, а в .a-файле её нет).
> И что в этом случае делать с плагинами???
> 
> я спашиваю так как начал пересобирать openldap??

Для начала стоит посмотреть на openldap-2.1.23-alt3.


-- 
ldv

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

Re: [sisyphus] .la files

[Alexey Morozov]

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

On Fri, Dec 05, 2003 at 01:35:11PM +0300, Dmitry V. Levin wrote:
> > Вообще, мне кажется, что на этом пути нас ждут вилы почище тех, которые
> > пытаемся убрать (из-за необходимости догадываться об имени библиотеки,
> > которую предлагается грузить: это ведь не только, и не столько somemodule.so,
> > сколько somemodule.so.<version> или вообще фиг знает что еще можно придумать,
> > - не зря же library_names придуман).
> 
> Тем, кому нужно использовать ltdl и library_names, придётся оставить
> .la-файлы.  А в простых случаях оно должно работать as is.
Осталось понять, кому нужно, а кто так, приидывается. Ладно, решабельная
задача.

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


> > Именно так. Так как в составе пакетов идут ltdl.* и ltmain.sh от libtool
> > _разных_ версий, то автоматического патча на этот повод не придумаешь.
> А "libtoolize --ltdl"?
Ну, видимо, придется. Хотя, на самом деле, судя по степени кривизны при
использовании autotools, процесс этот чреват :-)). Давеча ковырялся в
gtk-engines-1.x, кажется, очень удивлялся. откуда у меня из ./configure
ссылка на ltconfig, несмотря на свежий libtool и многократный libtoolize
--force

Оказалось, что эти <beep> просто положили в acinclude.m4 все макросы,
которые относятся к libtool. Так что, libtoolize --ltdl не всегда
сработает :-)

> > Хех. В dependency_libs указана /usr/lib/libMotherlib.la :-). Можете
> > проверить (н-р, в модулях того же libgnomeprint2). 
> Но ведь модули того же libgnomeprint2 наверняка слинкованы с -lMotherlib?
Если остается .la файл, то libtool при линковке глядит, в основном, в
него, а уж потом на то, кто там с кем слинкован :-).

> > Не рассчитаны кем? Автором? А [мне] не забить на то, что он рассчитывал, а
> > на что - нет. У нас же таки опенсорс, а не корпорация Сони с ее шифрованными
> > CD-дисками. На то он и линукс/эльф, чтобы иметь возможность хотеть странного.
> Если автор не предусмотрел возможность линковаться с плагинами, то вполне
> естественно, что придётся патчить как минимум makefile'ы.
Собственно говоря, "плагин" - это разделяемая библиотека с заранее
определенными точками входа. То есть, для того, чтобы линковаться с
плагинами, например, xmms'а (неважно, кем они писаны), достаточно
почитать соответствующий .h в _libxmms_ (или где у них там определен
интерфейс для плагинов). После чего можно ехать.

> > Можно, конечно, и документацию изменить до неузнаваемости, да только
> > это будет "уже не Джонни" (C).
> Я бы изменил и документацию.
Это круто. "Дорогой qmail'а идете, товарищи!" (моё) и

"Мы, в Microsoft, считаем, что любой стандарт всегда можно улучшить" (из
книжки про устройство каких-то потрохов в NT+, кажется; от MS Press)
Не боитесь, что Вам запретят распространять libtool разгневанные авторы?
:-)


На самом деле, некоторое предварительное решение находится здесь
http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg00844.html
(нарыл вчера). Оно по-прежнему не учитывает необходимости сохранения
dependency_libs для статических библиотек, и оно требует пересоздания
libtool'овых потрохов для каждого пакета (libtoolize --force в массы!)
Автор пока молчит, если ничего не изменится, я сам подправлю все это
барахло, так, чтобы при статической сборке использовались dependency_libs.
Судя по всему, там все же, не так много надо будет править.


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

[sisyphus] [OT] Re: .la files

[Andrey Khavryuchenko]

Alexey,

"AM" == Alexey Morozov wrote:

 AM> On Fri, Dec 05, 2003 at 01:35:11PM +0300, Dmitry V. Levin wrote:
 >> Отец Всех Дистрибутивов?
 AM> :-)) RH, что-ли? :-)

Тогда Slackware - это мама :)

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

Re: [sisyphus] .la files

[Dmitry V. Levin]

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

On Fri, Dec 05, 2003 at 05:39:01PM +0600, Alexey Morozov wrote:
> On Fri, Dec 05, 2003 at 01:35:11PM +0300, Dmitry V. Levin wrote:
> > > Вообще, мне кажется, что на этом пути нас ждут вилы почище тех, которые
> > > пытаемся убрать (из-за необходимости догадываться об имени библиотеки,
> > > которую предлагается грузить: это ведь не только, и не столько somemodule.so,
> > > сколько somemodule.so.<version> или вообще фиг знает что еще можно придумать,
> > > - не зря же library_names придуман).
> > 
> > Тем, кому нужно использовать ltdl и library_names, придётся оставить
> > .la-файлы.  А в простых случаях оно должно работать as is.
> Осталось понять, кому нужно, а кто так, приидывается. Ладно, решабельная
> задача.

Всякий, кто не использует ltdl, прикидывается.
Это можно nm'ом проверить.

> > > Именно так. Так как в составе пакетов идут ltdl.* и ltmain.sh от libtool
> > > _разных_ версий, то автоматического патча на этот повод не придумаешь.
> > А "libtoolize --ltdl"?
> Ну, видимо, придется. Хотя, на самом деле, судя по степени кривизны при
> использовании autotools, процесс этот чреват :-)). Давеча ковырялся в
> gtk-engines-1.x, кажется, очень удивлялся. откуда у меня из ./configure
> ссылка на ltconfig, несмотря на свежий libtool и многократный libtoolize
> --force
> 
> Оказалось, что эти <beep> просто положили в acinclude.m4 все макросы,
> которые относятся к libtool. Так что, libtoolize --ltdl не всегда
> сработает :-)

Поскольку "libtoolize --ltdl" копирует /usr/share/libtool/libltdl в
сборочное дерево, работать оно всё-таки будет.

> > > Хех. В dependency_libs указана /usr/lib/libMotherlib.la :-). Можете
> > > проверить (н-р, в модулях того же libgnomeprint2). 
> > Но ведь модули того же libgnomeprint2 наверняка слинкованы с -lMotherlib?
> Если остается .la файл, то libtool при линковке глядит, в основном, в
> него, а уж потом на то, кто там с кем слинкован :-).

Нет, libtool даже не смотрит, кто там с кем слинкован.

> > > Можно, конечно, и документацию изменить до неузнаваемости, да только
> > > это будет "уже не Джонни" (C).
> > Я бы изменил и документацию.
> Это круто. "Дорогой qmail'а идете, товарищи!" (моё) и
> 
> "Мы, в Microsoft, считаем, что любой стандарт всегда можно улучшить" (из
> книжки про устройство каких-то потрохов в NT+, кажется; от MS Press)
> Не боитесь, что Вам запретят распространять libtool разгневанные авторы?
> :-)

Этим авторам ещё работать и работать надо, а не гневаться.

> На самом деле, некоторое предварительное решение находится здесь
> http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg00844.html
> (нарыл вчера). Оно по-прежнему не учитывает необходимости сохранения
> dependency_libs для статических библиотек, и оно требует пересоздания
> libtool'овых потрохов для каждого пакета (libtoolize --force в массы!)

Да, это я уже обдумывал.  К сожалению, "libtoolize --force" в массы
обойдётся на гораздо дороже.

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


-- 
ldv

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

Re: [sisyphus] .la files

[Alexey Morozov]

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

On Fri, Dec 05, 2003 at 03:06:35PM +0300, Dmitry V. Levin wrote:
> > Осталось понять, кому нужно, а кто так, приидывается. Ладно, решабельная
> > задача.
> Всякий, кто не использует ltdl, прикидывается.
> Это можно nm'ом проверить.
Даже если это пострипанное приложение с convenience library? Сомневаюсь.

> > Если остается .la файл, то libtool при линковке глядит, в основном, в
> > него, а уж потом на то, кто там с кем слинкован :-).
> Нет, libtool даже не смотрит, кто там с кем слинкован.
Ну, тем более.

> > Не боитесь, что Вам запретят распространять libtool разгневанные авторы?
> > :-)
> Этим авторам ещё работать и работать надо, а не гневаться.
:-). Даже если и так, Copyright (или Copyleft) никто не отменял.
Поэтому попросить не распространять это как libtool вполне можно.

> > На самом деле, некоторое предварительное решение находится здесь
> > http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg00844.html
> > (нарыл вчера). Оно по-прежнему не учитывает необходимости сохранения
> > dependency_libs для статических библиотек, и оно требует пересоздания
> > libtool'овых потрохов для каждого пакета (libtoolize --force в массы!)
> Да, это я уже обдумывал.  К сожалению, "libtoolize --force" в массы
> обойдётся на гораздо дороже.
Гхм. Зато хотя бы какое-то подобие правильного решения.


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

Re: [sisyphus] [JT] Re: .la files

[Alexey Morozov]

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

On Fri, Dec 05, 2003 at 01:49:24PM +0200, Andrey Khavryuchenko wrote:
>  AM> On Fri, Dec 05, 2003 at 01:35:11PM +0300, Dmitry V. Levin wrote:
>  >> Отец Всех Дистрибутивов?
>  AM> :-)) RH, что-ли? :-)
> Тогда Slackware - это мама :)
По-моему, слакварь уже давно не претендовала на "инновационность".

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