[sisyphus] .la files

[Alexey Morozov]

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

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