После обновления Qt5 при запуске любой программы, использующей libQt5Core, получаю ошибку $ bibletime bibletime: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory $ epmqf /usr/lib64/libQt5Core.so.5 $ rpm -qf /usr/lib64/libQt5Core.so.5 libqt5-core-5.11.1-alt2.S1.x86_64 Note: /usr/lib64/libQt5Core.so.5 is link to /usr/lib64/libQt5Core.so.5.11.1 $ rpm -qf /usr/lib64/libQt5Core.so.5.11.1 libqt5-core-5.11.1-alt2.S1.x86_64 $ rpm -V libqt5-core (ничего) $ /usr/lib64/libQt5Core.so.5 This is the QtCore library version Qt 5.11.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.3.1 20180712 (ALT 7.3.1-alt5)) Copyright (C) 2016 The Qt Company Ltd. Contact: http://www.qt.io/licensing/ Installation prefix: /usr/share/qt5 Library path: /usr/lib64 Include path: /usr/include/qt5 Processor features: sse3 sse2[required] ssse3 cmpxchg16b sse4.1 sse4.2 popcnt aes avx Пытался спросить в рассылке, пробовал разные способы: https://lists.altlinux.org/pipermail/devel/2018-August/205227.html С виду всё хорошо. Раз только у меня, должно быть что-то локальное. Но я воспроизвёл на двух машинах.
Поскольку я получил такую же ошибку и в hasher, и на аппаратно другой машине (общее у них — использование ядра 2.6.32-ovz-el-alt162), а на машине с ядром 4.x проблемы нет, прихожу к выводу, что проблема вызвана ядром (взаимодействием ld-linux из glibc с ним).
2 LDV: Раз ты знаешь, кто виноват, расскажи подробности, пожалуйста.
(In reply to comment #2) > 2 LDV: Раз ты знаешь, кто виноват, расскажи подробности, пожалуйста. Понятия не имею, но по умолчанию glibc не виноват.
Значит, пусть будет ядро ovz-el.
Использование Сизифа на ядре 2.6.32-ovz-el не поддерживается.
(In reply to comment #5) > Использование Сизифа на ядре 2.6.32-ovz-el не поддерживается. Давно так стало?
Поступило совет, решающий проблему: strip --remove-section=.note.ABI-tag /usr/lib64/libQt5Core.so.5.11.1 Ссылки на эту тему: https://github.com/kdudka/csmock/commit/96a4a759a7de39f8da109202f4fa14c76a0ae68f https://github.com/Microsoft/WSL/issues/3023 abi-note.S breaks gABI on 64-bit systems https://sourceware.org/bugzilla/show_bug.cgi?id=23072 https://github.com/hjl-tools/linux-abi/commit/9a7bc47bf065405c2e7b6c46d692a7d137d5f544
(In reply to comment #7) > Поступило совет, решающий проблему: > strip --remove-section=.note.ABI-tag /usr/lib64/libQt5Core.so.5.11.1 Тогда возвращаю на пакет libqt5-core.
(В ответ на комментарий №7) > Поступил совет, решающий проблему: > strip --remove-section=.note.ABI-tag /usr/lib64/libQt5Core.so.5.11.1 Там говорится про эффект "атомной бомбы" от такого решения. Как я понял, objdump -s -j .note.ABI-tag /usr/lib/libQt5Core.so.5.11.1 покажет по ABI только требование ядра >= 3.17. Отрывать это для единичных "старьёвщиков" чревато тем, что запускаться-то оно будет, но когда и на чём "взорвётся" -- сказать сложно. Это требование там неслучайно.
(В ответ на комментарий №9) > (В ответ на комментарий №7) > > Поступил совет, решающий проблему: > > strip --remove-section=.note.ABI-tag /usr/lib64/libQt5Core.so.5.11.1 > > Там говорится про эффект "атомной бомбы" от такого решения. Как я понял, > objdump -s -j .note.ABI-tag /usr/lib/libQt5Core.so.5.11.1 покажет по ABI только > требование ядра >= 3.17. $ objdump -s -j .note.ABI-tag /usr/lib64/libQt5Core.so.5.11.1 /usr/lib64/libQt5Core.so.5.11.1: формат файла elf64-x86-64 Содержимое раздела .note.ABI-tag: 46f38c 04000000 10000000 01000000 474e5500 ............GNU. 46f39c 00000000 03000000 11000000 00000000 ................ Ну 03 11, похожее на 3.17, виднеется.
(В ответ на комментарий №10) [...] 03000000 11000000 00000000 ................ > > Ну 03 11, похожее на 3.17, виднеется. Да, 3.11.0, если точнее. 3.17 было у 5.10, если не ошибаюсь. Чтоб не дешифровать глазами, можно ещё readelf -n <путь>. Ссылки на gABI, SCO и утверждения про выравнивание -- правда не понятно, к чему там, насколько оно обязательно. Здесь действительно 32-бит реализация. note.ABI-tag полезен для динамического линкёра, чтоб не загрузить чего несовместимого.
В общем, кому очень хочется, смотрите http://git.altlinux.org/people/zerg/packages/qt5-base.git?p=qt5-base.git;a=blob;f=src/corelib/global/minimum-linux_p.h и http://git.altlinux.org/people/zerg/packages/qt5-base.git?p=qt5-base.git;a=blob;f=src/corelib/global/minimum-linux.S и т.д. P.S. Лично я в старых ядрах смысла не вижу.
(В ответ на комментарий №12) > Лично я в старых ядрах смысла не вижу. Точнее, если без renameat2 еще как-то не страшно, но без getentropy определенно не хочется.
Поэтому на старых ядрах решайте сами локально. Наверное, лучше пересобрать себе, а не стрипать, чтоб не взрывалось.
Меня больше возмущает отсутствие диагностики. Неужели для несовместимой библиотеки не нашлось другого сообщения об ошибке, кроме No such file or directory? На втором месте стоит возмущение самой привязкой к версии ядра ради системных вызовов. Эдак скоро мы дойдём до glibcfree-библиотек. Но главная причина в том, что getrandom появилась в glibc слишком поздно (а по-хорошему должна была появиться _до_ её появления в ядре Linux), и это привело к необходимости обходиться без неё, и свою рол прослойки совместимости она не сыграла. Статья про getrandom в glibc, которое туда добиралось пару лет после его появления в ядре: https://lwn.net/Articles/711013/
(В ответ на комментарий №11) > (В ответ на комментарий №10) > [...] 03000000 11000000 00000000 ................ > > > > Ну 03 11, похожее на 3.17, виднеется. > > Да, 3.11.0, если точнее. 3.17 было у 5.10, если не ошибаюсь. Чтоб не 0x11 это 17
(В ответ на комментарий №12) > В общем, кому очень хочется, смотрите Спасибо, интересно! Теперь стало понятнее. Одно дело догадываться, другое -- знать наверняка. (В ответ на комментарий №16) > > > Ну 03 11, похожее на 3.17, виднеется. > > > > Да, 3.11.0, если точнее. 3.17 было у 5.10, если не ошибаюсь. Чтоб не > 0x11 это 17 Ох, ДА! > Неужели для несовместимой библиотеки не нашлось другого сообщения > об ошибке, кроме No such file or directory? Согласен, только камень в сторону динамического линкёра надо кидать. > Статья про getrandom в glibc, которое туда добиралось пару лет после его > появления в ядре: Спасибо, познавательно! > На втором месте стоит возмущение самой привязкой к версии ядра ради системных > вызовов. Эдак скоро мы дойдём до glibcfree-библиотек. Возможно, по каким-то причинам разработчики QtCore сочли неподходящей glibc реализацию fallback'а. Статья описывает эти возможные причины (и риски) поверхностно. > Но главная причина в том, что getrandom появилась в glibc слишком поздно Тоже досадно, но софт не пишется идеальным и законченным сразу. :) Особенно досадно, что приходится то и дело "приседать" для "поддержки штанов" всему старому.
