The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск системной библиотеки Glibc 2.32

06.08.2020 23:56

После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library (glibc) 2.32, которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2017. В состав нового выпуска включены исправления от 67 разработчиков.

Из реализованных в Glibc 2.32 улучшений можно отметить:

  • Добавлена поддержка процессоров Synopsys ARC HS (ARCv2 ISA). Для работы порта требуется как минимум binutils 2.32, gcc 8.3 и ядро Linux 5.1. Поддерживается три варианта ABI arc-linux-gnu, arc-linux-gnuhf и arceb-linux-gnu (big-endian);
  • Реализована загрузка модулей аудита, указанных в секциях DT_AUDIT и DT_DEPAUDIT исполняемого файла.
  • Для архитектуры powerpc64le реализована поддержка типа IEEE128 long double, включаемая при сборке с опцией "-mabi=ieeelongdouble".
  • Некоторые API аннотированы с использованием GCC-атрибута 'access', позволяющего при компиляции в GCC 10 генерировать более качественные предупреждения при определении возможных переполнений буферов и других вариантов выхода за допустимые границы.
  • Для Linux-систем реализованы функции pthread_attr_setsigmask_np и pthread_attr_getsigmask_np, дающие приложению возможность указать маску сигнала для потоков, созданных при помощи pthread_create.
  • Данные кодировок, информация о типах символов и таблицы транслитерации обновлены для поддержки спецификации Unicode 13.0.0;
  • Добавлен новый заголовочный файл <sys/single_threaded.h>, определяющий переменную __libc_single_threaded, которую можно использовать в приложениях для однопоточных оптимизаций.
  • Добавлены функции sigabbrev_np и sigdescr_np, возвращающие сокращённое название и описание сигнала (например, "HUP" и Hangup" для SIGHUP).
  • Добавлены функции strerrorname_np и strerrordesc_np, возвращающие имя и описание ошибки (например, "EINVAL" и "Invalid argument" для EINVAL).
  • Для платформы ARM64 добавлен флаг "--enable-standard-branch-protection" (или -mbranch-protection=standard в GCC), задействующий механизм ARMv8.5-BTI (Branch Target Indicator) для защиты выполнения наборов инструкций, на которые не должны выполняться переходы при ветвлении. Блокирование переходов на произвольные участки кода реализовано для противодействия созданию гаджетов в эксплоитах, использующих приёмы возвратно-ориентированного программирования (ROP - Return-Oriented Programming, атакующий не пытается разместить свой код в памяти, а оперирует уже имеющимися кусками машинных инструкций, завершающихся инструкцией возврата управления, из которых выстраиваются цепочка вызовов для получения нужной функциональности).
  • Проведена большая чистка устаревших возможностей, в том числе удалены опции "--enable-obsolete-rpc" и "--enable-obsolete-nsl", заголовочный файл <sys/sysctl.h>. Объявлены устаревшими функции sstk, siginterrupt, sigpause, sighold, sigrelse, sigignore и sigset, массивы sys_siglist, _sys_siglist и sys_sigabbrev, символы sys_errlist, _sys_errlist, sys_nerr и _sys_nerr, NSS-модуль hesiod.
  • ldconfig по умолчанию переведён на использование нового формата ld.so.cache, который поддерживается в glibc уже почти 20 лет.
  • Устранены уязвимости:
    • CVE-2016-10228 - зацикливание в утилите iconv, проявляющееся при запуске с опцией "-c", в случае обработки некорректных многобайтовых данных.
    • CVE-2020-10029 - повреждение стека при вызове тригонометрических функций с псевдонулевым аргументом.
    • CVE-2020-1752 - обращение к области памяти после её освобождения (use-after-free) в функции glob при раскрытии ссылки на домашний каталог ("~user") в путях.
    • CVE-2020-6096 - некорректная обработка на платформе ARMv7 отрицательных значений параметра в memcpy() и memmove(), определяющего размер копируемой области. Позволяет организовать выполнение кода при обработке в функциях memcpy() и memmove() определённым образом оформленных данных. Показательно, что проблема оставалась неисправленной почти два месяца с момента публичного раскрытия информации и пять месяцев с момента уведомления разработчиков Glibc.


  1. Главная ссылка к новости (https://sourceware.org/piperma...)
  2. OpenNews: Выпуск стандартной Си-библиотеки Musl 1.1.17 с устранением уязвимости
  3. OpenNews: Microsoft открыл код стандартной библиотеки С++, поставляемой в Visual Studio
  4. OpenNews: Выпуск системной библиотеки Glibc 2.31
  5. OpenNews: Критическая уязвимость в реализации функции memcpy для ARMv7 из состава Glibc
  6. OpenNews: Разработчики из Google предложили разработать свою libc для LLVM
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/53504-glibc
Ключевые слова: glibc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Повидло19 (?), 00:38, 07/08/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    > Добавлены функции strerrorname_np и strerrordesc_np

    Надо больше нестандартных вещей!

     
     
  • 2.29, Аноним (29), 12:32, 07/08/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    юзай win32, там все збс со стандартами, хе-хе
     
  • 2.30, Аноним (30), 13:13, 07/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен, из них потом и появляются стандарты.
     
     
  • 3.47, Андрей (??), 19:55, 10/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    То был сарказм.
     

  • 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.5, Аноним (5), 01:57, 07/08/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Откуда инфа про порядок каталогов, не подскажете?
     
     
  • 4.8, Аноним (2), 02:12, 07/08/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Собственное наблюдение.
     
  • 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.17, Аноним (2), 04:04, 07/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, посмотри где в двоичном коде либы встречается ее имя.
     
  • 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.

    Что сказать то хотел?

     
     
  • 5.26, anonymous yet another (?), 11:12, 07/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А... Уровень понятен. Тема для общения исчерпана.
     
     
  • 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.
     

  • 1.19, linuxbuild (ok), 07:48, 07/08/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отчет об обратной совместимости 2.31 и 2.32: https://abi-laboratory.pro/index.php?view=timeline&l=glibc
     
     
  • 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.dev/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;



    Даже не знаю, чему верить, и зачем я это сюда скопировал. :)

     
     
  • 3.38, linuxbuild (ok), 17:59, 07/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вы смотрите сорцы, а надо бинарный код.
     
     
  • 4.39, n00by (ok), 18:12, 07/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кому это надо? У меня всё есть. В машинном коде нет никаких union, никогда не было и быть не может (гипотетические архитектуры не рассматриваем).
     

  • 1.32, Аноним (32), 14:24, 07/08/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ждём переход на использование инклюзивных терминов. ;)
     
  • 1.37, Аноним (35), 17:41, 07/08/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > readelf -d bin
    > patchelf --remove-needed so bin

    Спасибо за полезные команды.

     
     
  • 2.44, Анонимуз (?), 16:51, 08/08/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Присоединяюсь к благодарному анониму.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру