On Fri, Dec 05, 2003 at 01:35:11PM +0300, Dmitry V. Levin wrote: > > Вообще, мне кажется, что на этом пути нас ждут вилы почище тех, которые > > пытаемся убрать (из-за необходимости догадываться об имени библиотеки, > > которую предлагается грузить: это ведь не только, и не столько somemodule.so, > > сколько somemodule.so. или вообще фиг знает что еще можно придумать, > > - не зря же 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 Оказалось, что эти просто положили в 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. Судя по всему, там все же, не так много надо будет править.