Почему ffmpeg связывается со слишком большим количеством библиотек?

#ffmpeg #linker #dynamic-linking

#ffmpeg #компоновщик #динамическое связывание

Вопрос:

Я пытаюсь создать разделяемые библиотеки ffmpeg для декодирования видео в системах Linux. Сборка выполняется в Arch Linux, но результирующие разделяемые библиотеки должны быть как можно более переносимыми.

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

Вот что я попробовал:

 $ git clone https://git.ffmpeg.org/ffmpeg.git --branch n4.3.1 --depth 1
$ cd ffmpeg
$ mkdir build
$ cd build
$ ../configure 
    --enable-shared 
    --disable-programs --disable-doc 
    --disable-avdevice --disable-postproc --disable-avfilter 
    --disable-autodetect
$ make -j9
 

Обратите --disable-autodetect внимание, что должно предотвращать автоматическое определение того, какие зависимости присутствуют в системе сборки.

И все же, когда я проверяю результирующие библиотеки, все они имеют зависимости, о которых я не просил. Например:

 $ ldd libavcodec/libavcodec.so
    linux-vdso.so.1 (0x00007ffcd73cd000)
    libswresample.so.3 => /usr/lib/libswresample.so.3 (0x00007fba1e45c000)
    libavutil.so.56 => /usr/lib/libavutil.so.56 (0x00007fba1e1a7000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007fba1e061000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fba1e03f000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007fba1de76000)
    libsoxr.so.0 => /usr/lib/libsoxr.so.0 (0x00007fba1ddf4000)
    libva-drm.so.2 => /usr/lib/libva-drm.so.2 (0x00007fba1dded000)
    libva.so.2 => /usr/lib/libva.so.2 (0x00007fba1ddc0000)
    libva-x11.so.2 => /usr/lib/libva-x11.so.2 (0x00007fba1ddb8000)
    libvdpau.so.1 => /usr/lib/libvdpau.so.1 (0x00007fba1ddb3000)     <- Why is this here?
    libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fba1dc72000)
    libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007fba1dc5d000)
    libmfx.so.1 => /usr/lib/libmfx.so.1 (0x00007fba1dc4d000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fba1dc47000)
    /usr/lib64/ld-linux-x86-64.so.2 (0x00007fba1f971000)
    libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007fba1dc06000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fba1dbf1000)
    libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007fba1dbe8000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fba1dbbc000)
    libstdc  .so.6 => /usr/lib/libstdc  .so.6 (0x00007fba1d9df000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fba1d9c5000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fba1d9c0000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fba1d9b8000)
 

Я также попытался явно перечислить все флаги отключения, такие как --disable-vdpau , но это ничего не изменило; libvdpau.so.1 по-прежнему отображается в ldd выходных данных.

Может быть, они просто связаны, но фактически не используются? readelf -d кажется, указывает в этом направлении:

 $ ls */*.so
libavcodec/libavcodec.so    libavutil/libavutil.so          libswscale/libswscale.so
libavformat/libavformat.so  libswresample/libswresample.so
$ readelf -d */*.so | grep 'Shared library:' | sort -u
 0x0000000000000001 (NEEDED)             Shared library: [libavcodec.so.58]
 0x0000000000000001 (NEEDED)             Shared library: [libavutil.so.56]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libswresample.so.3]
 

Это хороший и плотный набор зависимостей, как я на самом деле хочу, чтобы они были.

Так что, может быть, система сборки глупа и всегда добавляет все обнаруженные библиотеки в командную строку компоновщика в любом случае? Чтобы подавить это, я попытался добавить --extra-ldflags=-Wl,--as-needed , но это, похоже, тоже не имеет никакого эффекта.

Результирующая командная строка компоновщика выглядит следующим образом (сокращенно):

 $ make -n libavcodec/libavcodec.so.58
gcc 
    -shared 
    -Wl,-soname,libavcodec.so.58 
    -Wl,-Bsymbolic 
    -Wl,--version-script,libavcodec/libavcodec.ver 
    -Llibavcodec -Llibavdevice -Llibavfilter -Llibavformat -Llibavresample -Llibavutil -Llibpostproc -Llibswscale -Llibswresample 
    -Wl,--as-needed 
    -Wl,-z,noexecstack 
    -Wl,--warn-common 
    -Wl,-rpath-link=:libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample 
    -Wl,--as-needed 
    -o libavcodec/libavcodec.so.58 
    [...all .o files...] 
    -lswresample -lavutil -pthread -lm -lm -pthread -lm
 

Похоже -Wl,--as-needed , что он уже был добавлен в любом случае.

Интересно, -Llibavdevice что он также указан, хотя я перешел --disable-avdevice --disable-postproc --disable-avfilter к сценарию настройки. Это может быть подсказкой: это подхватило бы мою систему libavdevice , которая, конечно, имеет гораздо больше зависимостей. Тем не менее, я ожидал -Wl,--as-needed бы также обрезать эти незавершенные зависимости.

Откуда берутся эти зависимости и как мне от них избавиться?

Ответ №1:

Конечно: при запуске ldd любые зависимости от других библиотек ffmpeg разрешаются теми, которые установлены в моей системе. И у них гораздо больше зависимостей. Итак, проблема была не в системе сборки, а в том, как я проверял результирующий результат.

Настройка LD_LIBRARY_PATH показывает истинный список транзитивных зависимостей:

 $ LD_LIBRARY_PATH=libavcodec:libavformat:libavutil:libswresample:libswscale ldd libavcodec/libavcodec.so
    linux-vdso.so.1 (0x00007fffaab0f000)
    libswresample.so.3 => libswresample/libswresample.so.3 (0x00007f9a8f213000)
    libavutil.so.56 => libavutil/libavutil.so.56 (0x00007f9a8ef6c000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f9a8ede0000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f9a8edbe000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f9a8ebf5000)
    /usr/lib64/ld-linux-x86-64.so.2 (0x00007f9a906e1000)