35297 2018-08-27 16:40:45 +0300 libQt5Core.so.5: cannot open shared object file: No such file or directory 2020-06-24 12:08:44 +0300 1 1 4 Development Sisyphus libqt5-core unstable all Linux CLOSED WONTFIX https://bugzilla.altlinux.org/show_bug.cgi?id=38421 P3 normal --- 1 lav zerg aen aspsk boris boyarsh glebfm iv kernelbot klark.devel ldv mike mithraen rider sbolshakov shrek sin vitty vsu vt zerg qa-sisyphus oldest_to_newest 173623 0 lav 2018-08-27 16:40:45 +0300 После обновления 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 С виду всё хорошо. Раз только у меня, должно быть что-то локальное. Но я воспроизвёл на двух машинах. 173631 1 lav 2018-08-28 00:29:22 +0300 Поскольку я получил такую же ошибку и в hasher, и на аппаратно другой машине (общее у них — использование ядра 2.6.32-ovz-el-alt162), а на машине с ядром 4.x проблемы нет, прихожу к выводу, что проблема вызвана ядром (взаимодействием ld-linux из glibc с ним). 173637 2 zerg 2018-08-28 11:49:01 +0300 2 LDV: Раз ты знаешь, кто виноват, расскажи подробности, пожалуйста. 173638 3 ldv 2018-08-28 12:02:12 +0300 (In reply to comment #2) > 2 LDV: Раз ты знаешь, кто виноват, расскажи подробности, пожалуйста. Понятия не имею, но по умолчанию glibc не виноват. 173639 4 zerg 2018-08-28 12:27:51 +0300 Значит, пусть будет ядро ovz-el. 173640 5 ldv 2018-08-28 12:33:52 +0300 Использование Сизифа на ядре 2.6.32-ovz-el не поддерживается. 173644 6 vt 2018-08-28 14:41:16 +0300 (In reply to comment #5) > Использование Сизифа на ядре 2.6.32-ovz-el не поддерживается. Давно так стало? 173651 7 lav 2018-08-28 21:39:26 +0300 Поступило совет, решающий проблему: 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 173653 8 ldv 2018-08-28 22:28:08 +0300 (In reply to comment #7) > Поступило совет, решающий проблему: > strip --remove-section=.note.ABI-tag /usr/lib64/libQt5Core.so.5.11.1 Тогда возвращаю на пакет libqt5-core. 173654 9 klark.devel 2018-08-28 23:44:06 +0300 (В ответ на комментарий №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. Отрывать это для единичных "старьёвщиков" чревато тем, что запускаться-то оно будет, но когда и на чём "взорвётся" -- сказать сложно. Это требование там неслучайно. 173655 10 lav 2018-08-28 23:54:42 +0300 (В ответ на комментарий №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, виднеется. 173660 11 klark.devel 2018-08-29 01:49:23 +0300 (В ответ на комментарий №10) [...] 03000000 11000000 00000000 ................ > > Ну 03 11, похожее на 3.17, виднеется. Да, 3.11.0, если точнее. 3.17 было у 5.10, если не ошибаюсь. Чтоб не дешифровать глазами, можно ещё readelf -n <путь>. Ссылки на gABI, SCO и утверждения про выравнивание -- правда не понятно, к чему там, насколько оно обязательно. Здесь действительно 32-бит реализация. note.ABI-tag полезен для динамического линкёра, чтоб не загрузить чего несовместимого. 173666 12 zerg 2018-08-29 10:01:36 +0300 В общем, кому очень хочется, смотрите 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. Лично я в старых ядрах смысла не вижу. 173667 13 zerg 2018-08-29 10:11:11 +0300 (В ответ на комментарий №12) > Лично я в старых ядрах смысла не вижу. Точнее, если без renameat2 еще как-то не страшно, но без getentropy определенно не хочется. 173668 14 zerg 2018-08-29 10:13:01 +0300 Поэтому на старых ядрах решайте сами локально. Наверное, лучше пересобрать себе, а не стрипать, чтоб не взрывалось. 173670 15 lav 2018-08-29 10:32:43 +0300 Меня больше возмущает отсутствие диагностики. Неужели для несовместимой библиотеки не нашлось другого сообщения об ошибке, кроме No such file or directory? На втором месте стоит возмущение самой привязкой к версии ядра ради системных вызовов. Эдак скоро мы дойдём до glibcfree-библиотек. Но главная причина в том, что getrandom появилась в glibc слишком поздно (а по-хорошему должна была появиться _до_ её появления в ядре Linux), и это привело к необходимости обходиться без неё, и свою рол прослойки совместимости она не сыграла. Статья про getrandom в glibc, которое туда добиралось пару лет после его появления в ядре: https://lwn.net/Articles/711013/ 173678 16 lav 2018-08-29 12:12:10 +0300 (В ответ на комментарий №11) > (В ответ на комментарий №10) > [...] 03000000 11000000 00000000 ................ > > > > Ну 03 11, похожее на 3.17, виднеется. > > Да, 3.11.0, если точнее. 3.17 было у 5.10, если не ошибаюсь. Чтоб не 0x11 это 17 173681 17 klark.devel 2018-08-29 13:28:07 +0300 (В ответ на комментарий №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 слишком поздно Тоже досадно, но софт не пишется идеальным и законченным сразу. :) Особенно досадно, что приходится то и дело "приседать" для "поддержки штанов" всему старому.