Bug 35297

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

После обновления 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

С виду всё хорошо. Раз только у меня, должно быть что-то локальное. Но я воспроизвёл на двух машинах.

Comment 1

Vitaly Lipatov 2018-08-28 00:29:22 MSK

Поскольку я получил такую же ошибку и в hasher, и на аппаратно другой машине (общее у них — использование ядра 2.6.32-ovz-el-alt162), а на машине с ядром 4.x проблемы нет, прихожу к выводу, что проблема вызвана ядром (взаимодействием ld-linux из glibc с ним).

Comment 2

Sergey V Turchin 2018-08-28 11:49:01 MSK

2 LDV: Раз ты знаешь, кто виноват, расскажи подробности, пожалуйста.

Comment 3

Dmitry V. Levin 2018-08-28 12:02:12 MSK

(In reply to comment #2)
> 2 LDV: Раз ты знаешь, кто виноват, расскажи подробности, пожалуйста.

Понятия не имею, но по умолчанию glibc не виноват.

Comment 4

Sergey V Turchin 2018-08-28 12:27:51 MSK

Значит, пусть будет ядро ovz-el.

Comment 5

Dmitry V. Levin 2018-08-28 12:33:52 MSK

Использование Сизифа на ядре 2.6.32-ovz-el не поддерживается.

Comment 6

Vitaly Chikunov 2018-08-28 14:41:16 MSK

(In reply to comment #5)
> Использование Сизифа на ядре 2.6.32-ovz-el не поддерживается.

Давно так стало?

Comment 7

Vitaly Lipatov 2018-08-28 21:39:26 MSK

Поступило совет, решающий проблему:
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

Comment 8

Dmitry V. Levin 2018-08-28 22:28:08 MSK

(In reply to comment #7)
> Поступило совет, решающий проблему:
> strip --remove-section=.note.ABI-tag /usr/lib64/libQt5Core.so.5.11.1

Тогда возвращаю на пакет libqt5-core.

Comment 9

Leonid Krivoshein 2018-08-28 23:44:06 MSK

(В ответ на комментарий №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. Отрывать это для единичных "старьёвщиков" чревато тем, что запускаться-то оно будет, но когда и на чём "взорвётся" -- сказать сложно. Это требование там неслучайно.

Comment 10

Vitaly Lipatov 2018-08-28 23:54:42 MSK

(В ответ на комментарий №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, виднеется.

Comment 11

Leonid Krivoshein 2018-08-29 01:49:23 MSK

(В ответ на комментарий №10)
[...] 03000000 11000000 00000000  ................
> 
> Ну 03 11, похожее на 3.17, виднеется.

Да, 3.11.0, если точнее. 3.17 было у 5.10, если не ошибаюсь. Чтоб не дешифровать глазами, можно ещё readelf -n <путь>. Ссылки на gABI, SCO и утверждения про выравнивание -- правда не понятно, к чему там, насколько оно обязательно. Здесь действительно 32-бит реализация. note.ABI-tag полезен для динамического линкёра, чтоб не загрузить чего несовместимого.

Comment 12

Sergey V Turchin 2018-08-29 10:01:36 MSK

В общем, кому очень хочется, смотрите
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.
Лично я в старых ядрах смысла не вижу.

Comment 13

Sergey V Turchin 2018-08-29 10:11:11 MSK

(В ответ на комментарий №12)
> Лично я в старых ядрах смысла не вижу.
Точнее, если без renameat2 еще как-то не страшно, но без getentropy определенно не хочется.

Comment 14

Sergey V Turchin 2018-08-29 10:13:01 MSK

Поэтому на старых ядрах решайте сами локально.

Наверное, лучше пересобрать себе, а не стрипать, чтоб не взрывалось.

Comment 15

Vitaly Lipatov 2018-08-29 10:32:43 MSK

Меня больше возмущает отсутствие диагностики. Неужели для несовместимой библиотеки не нашлось другого сообщения об ошибке, кроме No such file or directory?

На втором месте стоит возмущение самой привязкой к версии ядра ради системных вызовов. Эдак скоро мы дойдём до glibcfree-библиотек.

Но главная причина в том, что getrandom появилась в glibc слишком поздно (а по-хорошему должна была появиться _до_ её появления в ядре Linux), и это привело к необходимости обходиться без неё, и свою рол прослойки совместимости она не сыграла.

Статья про getrandom в glibc, которое туда добиралось пару лет после его появления в ядре:
https://lwn.net/Articles/711013/

Comment 16

Vitaly Lipatov 2018-08-29 12:12:10 MSK

(В ответ на комментарий №11)
> (В ответ на комментарий №10)
> [...] 03000000 11000000 00000000  ................
> > 
> > Ну 03 11, похожее на 3.17, виднеется.
> 
> Да, 3.11.0, если точнее. 3.17 было у 5.10, если не ошибаюсь. Чтоб не
0x11 это 17

Comment 17

Leonid Krivoshein 2018-08-29 13:28:07 MSK

(В ответ на комментарий №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 слишком поздно

Тоже досадно, но софт не пишется идеальным и законченным сразу. :) Особенно досадно, что приходится то и дело "приседать" для "поддержки штанов" всему старому.