| 1.1, Повидло19 (?), 00:38, 07/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– | |
> Добавлены функции strerrorname_np и strerrordesc_np
Надо больше нестандартных вещей!
| | |
| 1.2, Аноним (2), 01:33, 07/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Раз уж речь зашла о программировании, кто-нибудь знает, как удалить зависимость из бинарника или библиотеки? Без пересборки, конечно. Минорные зависимости я уже научился править в двоичном редакторе wxHexEditor, очень удобно. Собрал ffmpeg и он не конфликтует с системными либами. Но если нужно добавить больше цифр или вообще выпилить имя либы, прокатит ли заменить пробелами, или надо как-то вставить нулевые символы 00 или можно удалять со сдвигом? Вот, последнего боюсь. Может, есть какая-то утилита? Я находил одну, но после нее ldd стал жаловаться, что файл покоцан.
Дело в том, что у меня ffmpeg собран с vapoursynth, а vapoursynth тянет libpython. ldd показывает и зависимости зависимостей. То есть, мне надо удалить vapoursynth строчку из бинарника ffmpeg и/или его shared либ. Я думаю, ffmpeg после этого запустится, ведь он использует его только, если явно попросить. Мне бы это пригодилось, потому что у меня неоднозначное отношение к этим проектам. Автор vapoursynth тот еще хмырь и иногда на меня находит вычистить следы питона. Вообще, полезная бы фича была, как игнорирование зависимостей в пакетом менеджере. А то ставишь mplayer, он тащить smbclient, тот тащит python. пакетный менеджер можно обмануть, но бинарник все равно не запускается. Хотя, уверен, что samba нужна mplayer'у далеко не всегда.
Кстати, недостаточно переименовать библиотеку. В ней еще зашито настоящее имя, на которое смотрит ldconfig. Вот оно правится в двоичном редакторе.
| | |
| |
| 2.3, Аноним (3), 01:46, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> ffmpeg собран с vapoursynth, а vapoursynth тянет libpython.
В ffmpeg есть точки импорта из vapoursynth (вызываемые функции), если затрёшь имя либы, загрузчик не сможет найти этот импорт и ничего тебе не запустит. Связывание идёт в момент загрузки, а не тогда, когда ты соберёшься вызывать ф-ю.
| | |
| |
| 3.6, Аноним (2), 02:02, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Жалко. Я сначала хотел сделать staic build, как тут https://www.johnvansickle.com/ffmpeg
Но оказывается опция --enable-static отвечает только за то, что не создаются 8 собственных shared либ. Остальная куча зависимостей указывает на системные и на другом дистре не запускается (без плясок).
Вот тут https://github.com/zimbatm/ffmpeg-static/blob/master/build.sh для полной портативности используются опции
./configure --pkg-config-flags="--static" --extra-ldexeflags="-static"
но с ними pkg-config ffmpeg'а (./configure) не находит системные либы. Я так понял они тоже должны быть скопированы в /usr/local
К тому же сильно жирно держать три статичных копии ffmpeg, ffprobe и ffplay. Поэтому остановился на shared, и библиотеки легко подменять.
configure использовал такой:
--enable-pic --enable-gpl --enable-version3 --enable-nonfree --enable-shared --disable-static --disable-debug --disable-doc --enable-avisynth --enable-frei0r --enable-gcrypt --enable-gmp --enable-gnutls --enable-gray --enable-libdav1d --enable-librav1e --enable-libaom --enable-libass --enable-ladspa --enable-libbluray --enable-libcdio --enable-libdc1394 --enable-libfdk-aac --enable-libfontconfig --enable-libfreetype --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libopus --enable-libpulse --enable-librubberband --enable-librtmp --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libxml2 --enable-libzimg --enable-libzvbi --enable-vapoursynth --enable-openal
| | |
| |
| 4.7, Аноним (2), 02:11, 07/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Интересно, статичная сборка ffmpeg заглотит в себя libpython или он так и будет висеть внешкой? Прямой зависимости от него нет. Никто не собирает static ffmpeg с vapoursynth. А вот с avisynth (раньше avxsynth) собирают, даже в репах Ubuntu 16.04 с ним собрано. И в Арче. Чем хорош ависинт, он не привязывает свою библиотеку. А мерзкий vapoursynth привязывает даже питона (наверное, поэтому в арче без vapoursynth).
Avisynth хорош, но плагинов для него почти нет.
Найдутся ли знающие люди, которые смогут портировать TIVTC? https://github.com/pinterf/TIVTC/issues/14
Автор vapoursynth'а сказал, что ему это не интересно http://www.vapoursynth.com/discussion/#comment-18812
| | |
| |
| 5.10, Аноним (2), 02:22, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Никто не собирает static ffmpeg с vapoursynth
Правильнее было бы это назвать super static или portable static.
| | |
| 5.40, с (?), 01:27, 08/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
А в чем проблема-то, запускай сборку с VERBOSE=1 копируй команду которая собирает конечный бинарник, заменяй в ней динамическую линковку на статическую и делов.
Эх, молодеж, толи дело раньше, gcc приходилось скриптом подменять, чтобы когда надо нужные параметры подставлять..
| | |
|
| 4.9, Аноним (2), 02:17, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> configure использовал такой
Конечно, все внешние библиотеки самосборные первой свежести, а не из репозиторного xenial'овского старья. Ох, и намучился я с ними. Местами, свежее даже, чем тут https://www.johnvansickle.com/ffmpeg
И это в Ubuntu Xenial 2016 года выпуска.
| | |
|
|
| 2.4, Аноним (2), 01:51, 07/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> не конфликтует с системными либами
Если быть точнее, в Ubuntu 16.04 перекрываются
libxvidcore.so.4
libmp3lame.so.0
libvorbis.so.0
libopus.so.0
libtwolame.so.0
libwavpack.so.1
я все заменил на so.5
x264, x265, libvpx, libwebp, libfdk-aac не конфликтуют, но я на всякий случай их тоже заменил на so.9
Хотя, с неродными библиотеки (и в ту и в другую сторону) проги как правило работают. Например, ffmpeg собран с новым libopus, но при работе используется старый. В результате в консоли жалуется, что какие-то фичи not implemented, но кодирует.
Я заметил, что для бинарников приоритет каталогов выглядит так (при совпадении имен используется такой порядок загрузки):
~/.local/bin (есть не во всех дистрах, тогда, наверное ~/bin)
/usr/local/bin
/usr/bin
А вот с либами все наоборот. По умолчанию используются системные:
/usr/lib/i386-linux-gnu
/usr/local/lib
/usr/lib
(насчет ~/.local/lib пока не знаю)
| | |
| |
| 3.12, Аноним (12), 03:17, 07/08/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Расскажите ему кто-нибудь про LD_LIBRARY_PATH -- эта переменная используется как раз с целью запускать софт со своими специальными либами. Но нельзя заменить зависимости в бинарнике на другую версию таким образом и ожидать, что они будут работать. Они могут работать, однако надёжность такого решения околонулевая (зачем вообще трогать бинарники непонятно, когда они будут радостно линковаться и с симлинками).
| | |
| |
| 4.15, Аноним (2), 03:40, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Про LD_LIBRARY_PATH знаю. И вообще не проблема закинуть libvapoursynth.so и libpython.so куда-нибудь с глаз долой подальше в /usr/lib
Смысл в том, что я могу не захотеть держать эти библиотеки на винте в принципе из-за брезгливости.
То есть, проблема скорее эстетическая, чем практическая.
> зачем вообще трогать бинарники непонятно, когда они будут радостно линковаться и с симлинками
Ну вот прописано в бинарнике libmp3lame.so.0, а держать две версии с одинаковым именем в системе не очень хорошо, тем более по умолчанию используется старая системная. Для старого плеера это хорошо, а для новогособранного софта плохо. Тут, конечно, можно поплясать со всякими LD_LIBRARY_PATH (что неудобно, кстати) и прочими хитростями, не спорю.
| | |
| |
| 5.25, nobody (??), 10:41, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
переименуйте 1 букву, просто же, как это было сделано для OpenCL, чтобы он заработал на неподдерживаемых официально igpu
| | |
| 5.31, Ordu (ok), 13:25, 07/08/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > проблема скорее эстетическая, чем практическая.
Эстеты должны страдать. Решение эстетической проблемы будет эстетическим, а не техническим. Тебе лучше обратиться к художнику, дизайнеру, архитектору, или кому-нибудь ещё из этого направления, чтобы решить свою проблему. Не приставай к технарям, они решают практические проблемы.
| | |
|
|
| 3.13, Аноним (12), 03:26, 07/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
И про /etc/ld.so.conf с rpath/runpath и PATH заодно. Ещё rpath идёт до LD_LIBRARY_PATH, runpath после. Если в бинарнике по типу венды прописано rpath=. то это нужно учитывать.
| | |
| 3.21, anonymous yet another (?), 08:42, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Кроме упомянутых уже (LD_*_PATH, ld.so.conf) есть ещё (не предназначенные для "настройки") скрипты редактора связей/загрузчика. Т.е. в загрузчике некоторые пути изначально присутствуют. Какие --- зависит от системы (на разных платформах есть разные варианты), предназначения (у кросса там само-собой не то, что в родной), и желаний того, кто это собирал.
Из этого следует, что можно использовать собственный загрузчик (он указан в ELF-е) и, соответственно, грузить исходя из собственных оригинальных представлений о путях.
| | |
| 3.46, Аноним (46), 12:48, 10/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> насчет ~/.local/lib пока не знаю
А либы там и не ищутся. Можно сделать, чтобы искались, вписав этот путь в /etc/ld.so.conf.d/libc.conf и выполнив sudo ldconfig
Правда, про include и pkgconfig в ~/.local можно забыть.
То есть, сборочные файлы надо держать /usr/local, а ~/.local/lib это так - по быстрому закинуть либы и удалить.
| | |
|
| 2.11, Аноним (12), 03:12, 07/08/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Совсем не то, что ты спрашиваешь, но можно сделать пустую заглушку вида
void symname1(void){return;}
void symname2(void){return;}
gcc -s -shared -fpic -march=core2 -O2 -pipe -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,relro -Wl,-z,now -Wl,--hash-style=gnu -Wl,--no-copy-dt-needed-entries -Wall -Wextra syms.c -olibnametarget.so.1
и бинарник будет спешно линковаться с такой либой и работать, если тебе что-то в нём не нужно то ты и не заметишь разницы. Я пытался патчить экзешник (удаляя сиволы соответствующими утилитами), но все мои эксперименты приводили только к сегфолтам, в этом варианте экзешник вообще трогать не нужно и избавление от зависимостей происходит путём модификации окружения. Я так понял твой вариант это подсовывать либу иной версии, он никуда не годится, бинарной совместимости между разными версиями нет. Хотя даже может работать, я просто подсовываю симлинк на либу другой версии с нужным именем и не имею проблем, но не забываю, что это колхоз.
| | |
| |
| 3.16, Аноним (2), 04:03, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Я так понял твой вариант это подсовывать либу иной версии
Нет, я как раз стараюсь этого избежать
Я
1. переименовал новый libmp3lame.so.0 в libmp3lame.so.5
2. заменил 0 на 5 в самом файле libmp3lame.so.5 в двоичном редакторе
3. подправил la файл на имена libmp3lame.so и libmp3lame.so.5
4. удалил лишние симлинки и создал симлинк libmp3lame.so > libmp3lame.so.5
5. выполнил sudo ldconfig
6. собрал ffmpeg с опцией --enable-libmp3lame, он прилинковался к libmp3lame.so.5
Теперь в системе две разных библиотеки libmp3lame (новая и старая) с разным именем
A. /usr/lib/i386-linux-gnu/libmp3lame.so.0 (старая 3.99.5, ее использует системный софт)
B. /usr/lib/libmp3lame.so.5 (новая 3.100, ее использует только моя сборка ffmpeg)
К таким хитростям приходится прибегать, потому что в libmp3lame имя файла не меняется при обновлении самой библиотеки. Это, кстати, должно означать обратную совместимость, но решил не рисковать.
Аналогично, я поступил и с другими библиотеками.
Теперь
Есть новый самосборный бинарник /usr/local/bin/fdkaac, в котором прописано линковаться с новой libfdk-aac.so.2.
Я правлю с помощью двоичного редактора в fdkaac so.2 на so.5 и он линкуется теперь к либе /usr/lib/libfdk-aac.so.5 (как в примере B). Это та же самая либа, но с другим именем. В результате лишний libfdk-aac.so.2 можно удалить (который лежал бы, например, в /usr/local/lib/libfdk-aac.so.2).
Короче, жесть. Но я разобрался.
| | |
| |
| 4.18, Аноним (2), 04:07, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> должно означать обратную совместимость
Шиш там. Мой пример с libopus и варнингом filter not implemented.
| | |
|
|
| 2.14, Аноним (12), 03:39, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
>настоящее имя
В смысле dlopen? Dlopen можно перехватить и подменить. Если слинковано статически, то так просто не получится.
| | |
| |
| 3.22, anonymous yet another (?), 08:51, 07/08/2020 [^] [^^] [^^^] [ответить]
| –3 +/– | |
Учите матчасть.
Информация к размышлению (т.е. это не исчерпывающий ответ, а намёк про что надо идти читать):
<code>
readelf -d /lib/libc.so.6
Dynamic section at offset 0x1b4b80 contains 26 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
0x000000000000000e (SONAME) Library soname: [libc.so.6]
0x000000000000000c (INIT) 0x23b60
0x0000000000000019 (INIT_ARRAY) 0x1b2798
0x000000000000001b (INIT_ARRAYSZ) 16 (bytes)
0x0000000000000004 (HASH) 0x1adeb8
0x000000006ffffef5 (GNU_HASH) 0x300
0x0000000000000005 (STRTAB) 0x11d90
0x0000000000000006 (SYMTAB) 0x3fa8
0x000000000000000a (STRSZ) 24715 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000003 (PLTGOT) 0x1b6000
0x0000000000000002 (PLTRELSZ) 1128 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x20f38
0x0000000000000007 (RELA) 0x19540
0x0000000000000008 (RELASZ) 31224 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffc (VERDEF) 0x190a0
0x000000006ffffffd (VERDEFNUM) 32
0x000000000000001e (FLAGS) STATIC_TLS
0x000000006ffffffe (VERNEED) 0x19510
0x000000006fffffff (VERNEEDNUM) 1
0x000000006ffffff0 (VERSYM) 0x17e1c
0x000000006ffffff9 (RELACOUNT) 1211
0x0000000000000000 (NULL) 0x0
</code>
| | |
| |
| 4.23, Аноним (12), 09:10, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
>There is no dynamic section in this file.
Что сказать то хотел?
| | |
| |
| |
| 6.27, Аноним (12), 11:15, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> А... Уровень понятен. Тема для общения исчерпана.
Согласен, лучше бы и не высовывался раз нечего по теме добавить.
| | |
|
|
|
|
| 2.33, dviktor (?), 15:56, 07/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
sudo patchelf --remove-needed libvapoursynth.so /path/to/your/ffmpeg
| | |
| |
| 3.35, Аноним (35), 17:33, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
После этого readelf -d не показывает его в зависимостях, но все равно при запуске ошибка cannot open shared object file: No such file or directory
Посмотрел в двоичном редакторе, libvapoursynth.so все равно присутствует, несмотря на patchelf. Заменил эту надпись нулями 00. Теперь vapoursynth.so в бинарнике нет, но при запуске все равно ошибка cannot open shared object file: No such file or directory. Непонятно откуда он берется.
readelf -d показывает только прямые зависимости, а ldd зависимости зависимостей. ldd показывает, что зависимость от vapoursynth.so осталась. Значит это зависимость зависимости и надо патчить другие либы, libavformat скорее всего.
| | |
| |
| 4.45, dviktor (?), 19:55, 08/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
сделай lddtree для твоего бинарника, он показывает всё дерево зависимостей
| | |
|
|
| 2.34, Аноним (34), 16:31, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Дело в том, что у меня ffmpeg собран с vapoursynth, а vapoursynth тянет libpython. ldd показывает и зависимости зависимостей. То есть, мне надо удалить vapoursynth строчку из бинарника ffmpeg и/или его shared либ.
Так пересобери его без vapoursynth. лавров.апнг
| | |
| |
| 3.36, Аноним (35), 17:39, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Не охота несколько сборок держать. Но видимо придется. Один фиг патченные либы надо где-то хранить, не патчить же каждый раз. Но все равно команды полезные. mplayer мне пересобирать что-то не хочется, тем более его надо привязывать к либам ffmpeg 4 вместо системного 2.
| | |
|
| 2.41, winorun (?), 05:53, 08/08/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Для начала выбрось свой пакетный менедже и поставь aptitude. в нем убери установку рекомендованного . Для установки пакета без зависимостей есть force.
Теперь по теме. подключай пакеты исходного кода и устанавливай зависимости. далее собирай уже пакет с нужными опциями без vapoursynth и будет тебе счастье.
| | |
| |
| 3.42, winorun (?), 06:02, 08/08/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
если зависимостей для сборки по версиям не хватит собирай в opt, но тогда интеграцию потеряещь.
P.s.
Mplayer поменяй на MPV
| | |
|
| 2.43, Zenitur (ok), 11:48, 08/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Создать библиотеку-заглушку, которая имеет то же имя, но ничего не делает. Например apulse - правда, не совсем подходит в качестве примера, так как эта библиотека переадресовывает вызовы PulseAudio в ALSA.
| | |
|
| |
| 2.28, n00by (ok), 12:20, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
 1.
Binary compatibility report for glibc: 2.31 vs 2.32
Problems with Data Types, Medium Severity 1
Base type has been changed from union __jmpbuf_arch_t to struct __sigset_t of different format.
The fields or parameters of such data type may be incorrectly initialized or accessed by old client applications.
[−] affected symbols: 17 (1.7%)
epoll_pwait ( int epfd, struct epoll_event* events, int maxevents, int timeout, union __jmpbuf_arch_t const* set )
...
https://abi-laboratory.pro/index.php?view=compat_report&l=glibc&v1=2.31&v2=2.3
2.
int epoll_pwait(int epfd, struct epoll_event *events,
int maxevents, int timeout,
const sigset_t *sigmask);
https://www.opennet.ru/man.shtml?topic=epoll_pwait&category=2&russian=2
3.
/* Same as epoll_wait, but the thread's signal mask is temporarily
and atomically replaced with the one provided as parameter.
This function is a cancellation point and therefore not marked with
__THROW. */
extern int epoll_pwait (int __epfd, struct epoll_event *__events,
int __maxevents, int __timeout,
const __sigset_t *__ss);
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/sys/e
4.
typedef union
{
__sigset_t __saved_mask_compat;
struct
{
__jmp_buf_sigset_t __saved_mask;
/* Used for shadow stack pointer. NB: Shadow stack pointer
must have the same alignment as __saved_mask. Otherwise
offset of __saved_mask will be changed. */
unsigned long int __shadow_stack_pointer;
} __saved;
} __jmpbuf_arch_t;
Даже не знаю, чему верить, и зачем я это сюда скопировал. :)
| | |
| |
| |
| 4.39, n00by (ok), 18:12, 07/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Кому это надо? У меня всё есть. В машинном коде нет никаких union, никогда не было и быть не может (гипотетические архитектуры не рассматриваем).
| | |
|
|
|
| 1.37, Аноним (35), 17:41, 07/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> readelf -d bin
> patchelf --remove-needed so bin
Спасибо за полезные команды.
| | |
|
