LINUX.ORG.RU

libavformat не видит libavutil

 ,


0

1

Добрый день, ЛОР.

Пытаюсь собрать на древней системе ffmpeg 3.2. Старый ffmpeg и ffmpeg-devel снёс.

Сделал:

./configure --disable-yasm --disable-zlib
make

От рута:

make install

Библиотеки установились в /usr/local/lib.

Добавил в /etc/ld.so.conf.d текстовый файл с упоминанием /usr/local/lib, выполнил ldconfig.

Запущенный ffmpeg показывает:

ffmpeg version 3.2 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.1.3 (GCC) 20080704 (prerelease)
  configuration: --disable-yasm --disable-zlib
  libavutil      55. 34.100 / 55. 34.100
  libavcodec     57. 64.100 / 57. 64.100
  libavformat    57. 56.100 / 57. 56.100
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter     6. 65.100 /  6. 65.100
  libswscale      4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100

Теперь я запускаю свой кутешный проект. В файле проекта есть ссылки на библиотеки ffmpeg:

unix {
LIBS += -lavutil -lavformat -lavcodec -lswscale
}

Мои исходники компилируются, но линкер обламывается со следующей формулировкой:

/usr/local/lib/libavformat.a(apngenc.o): In function `apng_write_chunk':
/home/user/projects/ffmpeg-3.2/libavformat/apngenc.c:61: undefined reference to `av_crc_get_table'
/home/user/projects/ffmpeg-3.2/libavformat/apngenc.c:69: undefined reference to `av_crc'
/home/user/projects/ffmpeg-3.2/libavformat/apngenc.c:72: undefined reference to `av_crc'

То есть программа подцепляет libavformat.a, а уже в нём почему-то не получается подцепить имя, заданное в libavutil.a/crc.o

Раньше тот же проект без проблем собирался в Windows, а также в Linux с более старой версией ffmpeg, которую опакечивал не я (но условные компиляции в проекте присутствуют, да).

★★★★★

Раньше тот же проект без проблем собирался в Windows

Насколько я помню, виндовый link.exe продвинутей линуксового ld/collect1 и строит дерево, поэтому ему порядок линковки не важен.

А в Linux'ах нормального линковщика до сих пор из коробки не завезли, поэтому порядок тут значение имеет.

Четыре года прошло:

bbqscreen_client (комментарий)

А такая же ошибка.

EXL ★★★★★ ()
Ответ на: комментарий от EXL

В ld можно обернуть список библиотек в -Wl,--start-group и -Wl,--end-group и игнорировать порядок ценой большего потребления ресурсов, которые требуются чтобы не зависеть от порядка.

xaizek ★★★★★ ()
Ответ на: комментарий от xaizek

И почему такое поведение не выставлено в GCC до сих пор по-умолчанию?

Хотя, что толку в экономии потребления ресурсов, когда что ld, что gold — тупо тормоза в сравнении с тем же lld:

https://lld.llvm.org/#performance

EXL ★★★★★ ()
Ответ на: комментарий от EXL

И почему такое поведение не выставлено в GCC до сих пор по-умолчанию?

Этого мне не известно.

тупо тормоза в сравнении с тем же lld

Я знаю, что gold в отличии от ld поддерживает не все возможности линкер-скриптов, а как с этим у lld?

xaizek ★★★★★ ()
Ответ на: комментарий от xaizek

не все возможности линкер-скриптов, а как с этим у lld?

Ну они у себя заявляют:

LLD is a drop-in replacement for the GNU linkers. That accepts the same command line arguments and linker scripts as GNU.

Но при этом отмечают:

Some very old features for ancient Unix systems (pre-90s or even before that) have been removed. Some default settings have been tuned for the 21st century. For example, the stack is marked as non-executable by default to tighten security.

В любом случае завязываться на один тулчейн, будь то GCC, Clang или MSVC, я думаю, не стоит.

EXL ★★★★★ ()

Про порядок уже сказали, avformat дёргает avutil, потому avformat должен идти раньше

Harald ★★★★★ ()
Ответ на: комментарий от xaizek

А если порядок поменять?

Спасибо, помогло!

...Где-то в подсознании шевелилась мысль, что порядок библиотек может иметь значение, но мозг тут же отмёл её как несуразную. А оно, оказывается, вон как...

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

Если интересно, вот тут можно почитать как линкер обрабатывает статические библиотеки.

xaizek ★★★★★ ()
Ответ на: комментарий от xaizek

В общем, финальный порядок, с которым программа собралась и заработала, выглядит так:

unix {
LIBS += -lavformat -lavcodec -lavutil -lswscale -lswresample
}
При этом моя программа libswresample не использует, но она нужна ещё кому-то, кажется, libswscale.

Всё понятно. Одно непонятно — почему тот же проект на той же системе нормально собирался со старым ffmpeg версии аж 0.5 (только тот ffmpeg не собирался из исходников, а был поставлен из родной RPM)...

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

почему тот же проект на той же системе нормально собирался со старым ffmpeg версии аж 0.5 (только тот ffmpeg не собирался из исходников, а был поставлен из родной RPM)...

Может там были не статические библиотеки, а динамические. Либо ещё есть *.la файлы от libtool, возможно они были (они вроде зависимости статических библиотек описывают).

xaizek ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.