ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Vitaly Lipatov <lav@altlinux.ru>
To: ALT Devel discussion list <devel@lists.altlinux.org>
Subject: [devel] Сборка ffmpeg в p8
Date: Fri, 21 Jul 2017 23:58:17 +0300
Message-ID: <58f1278e6dd77240719b6eb9db088beb@altlinux.ru> (raw)

Всем добрый день!

Вопрос о сборке ffmpeg в p8 очень интересный, потому что попытки его 
решения выявляют ряд проблем и ограничений, многие из которых не носят 
технического характера.
Так получилось, что так или иначе тему ffmpeg я обсуждал с разными 
специалистами, но они не всегда знали мнение друг друга, поэтому я хотел 
бы их увидеть в этой цепочке обсуждения.

На самом деле я очень мало разбираюсь в проблеме. Я не собирал ffmpeg, и 
не проводил ту большую работу, которую провёл rider@ в Сизифе, благодаря 
которой мы не только получили актуальную версию ffmpeg, но и знаем 
теперь о том, что переход возможен.

Итак. Как обычно, всё начинается с того, что почти все программы, 
хотящие воспроизводить видео, хотят использовать ffmpeg. Которого — 
неожиданно — в p8 нет.

Среди них такие базовые в наше время программы, как chromium и firefox.
Кстати, у них интересное отличие. Если chromium просто несёт ffmpeg 
внутри себя и собирает его в библиотеку, которую носит с собой, то 
firefox носит с собой некоторые огрызки и headers, а потом при 
исполнении перебирает по списку, что он может загрузить из
   "libavcodec-ffmpeg.so.57",
   "libavcodec-ffmpeg.so.56",
   "libavcodec.so.57",
   "libavcodec.so.56",
   "libavcodec.so.55",
   "libavcodec.so.54",
   "libavcodec.so.53",

Что интересно с chromium. Многие библиотеки, которые он несёт с собой, 
он собирает динамически и кладёт в свой каталог:
/usr/lib64/chromium/libffmpeg.so
/usr/lib64/chromium/libicui18n.so
/usr/lib64/chromium/libicuuc.so
/usr/lib64/chromium/libv8.so

Кто даёт гарантии, что какие-то библиотеки, используемые chromium, не 
слинкуются с какими-то системными вариантами этих библиотек и chromium 
не начнёт падать?
В тоже время один из аргументов против моего робкого предложения собрать 
ffmpeg в %_libdir/ffmpeg, чтобы он никому не мешал кроме тех, кто решит 
явно с ним линковаться, заключается как раз в попытке избежать такой 
ситуации.

Далее. Сейчас очень популярным является создание desktop-программ на 
движке Electon (всё началось с редактора Atom, потом MS Visual Studio 
Code, клиенты Skype, VK Messenger, разные там Franz, WebTorrent, 
PopcornTime, Sia UI и пр).
Если посмотреть на то, как electron собран, видно, с какими библиотеками 
он собран или носит с собой.
$ rpm -ql electron
/usr/lib64/electron/electron
/usr/lib64/electron/icudtl.dat
/usr/lib64/electron/libffmpeg.so
/usr/lib64/electron/libnode.so

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

Вот у нас (а может только у меня в системе) есть 3 библиотеки libpng 
одновременно:
$ ls /usr/lib64/libpng*.so.*.0 -1
/usr/lib64/libpng12.so.0.50.0
/usr/lib64/libpng15.so.15.28.0
/usr/lib64/libpng16.so.16.29.0
и этого не пугает никого.
В тоже время появление альтернативных библиотек ffmpeg выглядит страшно.

Я слышал простое предложение носить линковаться с ffmpeg статически. 
Конечно, я никогда не стану собирать незаметно ffmpeg внутри пакета и 
линковаться с ней. Я бы собрал некий ffmpeg-devel-static со статическими 
библиотеками и собирался с ней. Но если мы на простой проблеме так легко 
отказываемся от динамической линковки, зачем в других случаях 
рассказывать, как важно иметь возможность в случае необходимости 
пересобирать библиотеку с security fixes, не пересобирая все проекты, её 
использующие.
Я уж молчу о разделении памяти и совсем отдельная тема, что смена 
способа линковки может вызывать лицензионные столкновения.

Затрудняюсь привести все аргументы против сборки в p8, которые я услышал 
от уважаемых коллег. Мне показалось, что частично они защищают 
репозиторий от недальновидных мантейнеров, а частично выглядят немного 
смешно. И почти не носят технический характер. Поэтому я прошу, если 
аргументы против остались в силе, процитировать их здесь самостоятельно.

Закончу фразой, что репозиторий, в который нельзя собрать пакет, 
становится не интересен.


P.S.
А mplayer в Сизифе слинкован с десятками сумасшедших библиотек проекта 
samba. Видимо, со всем содержимым
/usr/lib64/samba/:
...
	libutil-tdb-samba4.so => /usr/lib64/samba/libutil-tdb-samba4.so 
(0x00007f3138760000)
	libsamba-sockets-samba4.so => 
/usr/lib64/samba/libsamba-sockets-samba4.so (0x00007f3138548000)
...

$ ldd /usr/bin/mplayer | grep samba | wc -l
54


-- 
С уважением,
Виталий Липатов,
Etersoft


             reply	other threads:[~2017-07-21 20:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 20:58 Vitaly Lipatov [this message]
2017-07-22  7:35 ` Sergey V Turchin
2017-07-22  9:30   ` [devel] bundled libraries Dmitry V. Levin
2017-07-22 10:23     ` Sergey V Turchin
2017-07-22  9:49   ` [devel] Сборка ffmpeg в p8 Alexey Gladkov
2017-07-22 10:17     ` Sergey V Turchin
2017-07-24  6:31   ` Alexey V. Vissarionov
2017-07-24  7:14     ` Hihin Ruslan
2017-07-24  7:41       ` Alexey V. Vissarionov
2017-07-24  7:48         ` Hihin Ruslan
2017-07-24  7:49         ` Hihin Ruslan
2017-07-24  7:51         ` Hihin Ruslan
2017-07-24  7:52         ` Sergey V Turchin
2017-07-24  7:52         ` Hihin Ruslan
2017-07-24  7:21     ` Sergey V Turchin
2017-07-24  7:50       ` Alexey V. Vissarionov
2017-07-24  8:05         ` Sergey V Turchin
2017-07-22  8:35   ` Motsyo Gennadi aka Drool
2017-10-07  6:56     ` Vitaly Lipatov
2017-10-09 14:35       ` Sergey V Turchin
2017-10-09 14:40       ` Sergey V Turchin
2017-10-09 14:50         ` Anton Farygin
2017-10-09 14:51           ` Sergey V Turchin
2017-10-13 14:29         ` Vitaly Lipatov
2017-10-13 14:40         ` Vitaly Lipatov
2017-10-14  7:45           ` Sergey V Turchin
2017-07-25 10:37 ` [devel] Сборка ffmpeg в p8 (mplayer в Сизифе слинкован с десятками сумасшедших библиотек проекта samba) Vladimir D. Seleznev
2017-07-27 20:32   ` Vitaly Lipatov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58f1278e6dd77240719b6eb9db088beb@altlinux.ru \
    --to=lav@altlinux.ru \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git