ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | libQt5Core.so.5: cannot open shared object file: No such file or directory | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Vitaly Lipatov <lav> |
| Component: | libqt5-core | Assignee: | Sergey V Turchin <zerg> |
| Status: | CLOSED WONTFIX | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P3 | CC: | aen, aspsk, boris, boyarsh, glebfm, iv, kernelbot, klark.devel, ldv, mike, mithraen, rider, sbolshakov, shrek, sin, vitty, vsu, vt, zerg |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.altlinux.org/show_bug.cgi?id=38421 | ||
|
Description
Vitaly Lipatov
2018-08-27 16:40:45 MSK
Поскольку я получил такую же ошибку и в 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 слишком поздно Тоже досадно, но софт не пишется идеальным и законченным сразу. :) Особенно досадно, что приходится то и дело "приседать" для "поддержки штанов" всему старому. |
