[devel] mplayer q

[=?iso-8859-1?q?led_=CE=C1_altlinux=2Eru?=]

Sunday, 18 November 2007 05:05:23 Alexey Tourbin написав:
> On Sun, Nov 18, 2007 at 05:46:55AM +0300, Денис Смирнов wrote:
> > On Sun, Nov 18, 2007 at 01:15:17AM +0300, Алексей Турбин wrote:
> > >> $ rpm -q mplayer
> > >> mplayer-1.0-alt35.25029.1
> > >> $ ldd -r /usr/bin/mplayer |grep directfb
> > >> libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
> > >> libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)
> > >> Можно эту феерию прекратить ?
> >
> > AT> А вот я говорил, что не надо увлекаться запаковской legacy библиотек!
> > AT> Лучше просто пересобраться всё с новой библиотекой.  И именно по этой
> > AT> причине -- если в адресном пространстве процесса окажется две
> > библиотеки AT> разных версий, то это скорее всего как минимум не будет
> > работать.
> >
> > А можно ли наши любимые скрипты при сборке rpm-пакета научить в такой
> > ситуации склеивать ласты?
>
> Можно завалить сборку mplayer с диагностикой что 'ldd /usr/bin/mplayer'
> даёт libdirectfb-*A* и libdirectfb-*B*.  Но это не вина
> /usr/bin/mplayer, а вина того, кто транзитивно (или "рекурсивно")
> вытягивает лишнюю версию libdirectfb.
>
> В общем-то после пересборки libcairo с новым libdirectfb сборка mplayer
> должна дать идентичный результат.  Казалось бы, на кой чёрт её заваливать?

После пересборки libcairo и установки её в систему получаем:
$ ldd -r /usr/bin/mplayer | grep directfb
libdirectfb-1.1.so.0 => /usr/lib64/libdirectfb-1.1.so.0 (0x00002b8c08f72000)
$

mplayer не пересобирался и не переустанавливался

___
Led.