[serge@yarilo libexec]$ qtpaths --install-prefix
/share/qt5

https://bugreports.qt.io/browse/QTBUG-82589

Created attachment 15954 [details]
Полный вывод предзагрузчика библиотек

LD_DEBUG=libs /lib64/ld-linux-x86-64.so.2 --inhibit-cache /usr/bin/kmail

(Ответ для Sergei Naumov на комментарий #0)
> path '/share/qt5/resources'
Где-то побились симлинки.

А если сделать
ln -s /usr/share /share
?

(Ответ для Sergey V Turchin на комментарий #5)
> А если сделать
> ln -s /usr/share /share
> ?

Завелось

(Ответ для Sergei Naumov на комментарий #6)
> (Ответ для Sergey V Turchin на комментарий #5)
> > А если сделать
> > ln -s /usr/share /share
> > ?
> 
> Завелось

 Но это как-то не правильно - лепить в корень море симлинков...

(Ответ для Sergei Naumov на комментарий #2)
> https://bugreports.qt.io/browse/QTBUG-82589
"Since /lib64 is a symlink to /usr/lib64, the paths /lib64/libQt5Core.so.5 an /usr/lib64/libQt5Core.so.5 are both valid."

Возможно, надо в filesystem добавить симлинк /share .

Или где-то порядок поиска каталогов библиотек поменять. Если найду в Qt, закостылю.

(In reply to Sergey V Turchin from comment #8)
> (Ответ для Sergei Naumov на комментарий #2)
> > https://bugreports.qt.io/browse/QTBUG-82589
> "Since /lib64 is a symlink to /usr/lib64, the paths /lib64/libQt5Core.so.5
> an /usr/lib64/libQt5Core.so.5 are both valid."
> 
> Возможно, надо в filesystem добавить симлинк /share .

Как у вас выглядит переменная PATH?

(In reply to Sergei Naumov from comment #0)
> После перехода на filesystem-3.1 перестал запускаться kmail. Видимо, не
> может правильно пути теперь находить:
> 
> [serge@yarilo ~]$ kmail
> Path override failed for key base::DIR_QT_LIBRARY_DATA and path
> '/share/qt5/resources'

Вопрос про PATH у меня был сюда, не туда его задал сначала.

> *** KMail got signal 11 (Exiting)
> *** Dead letters dumped.
> KCrash: Application 'kmail' crashing...
> The X11 connection broke: I/O error (code 1)
> XIO:  fatal IO error 2 (Нет такого файла или каталога) on X server ":0"
>       after 416 requests (416 known processed) with 0 events remaining.
> QObject::killTimer: Timers cannot be stopped from another thread
> QObject::~QObject: Timers cannot be stopped from another thread
> KCrash: Attempting to start /usr/libexec/drkonqi

(Ответ для Arseny Maslennikov на комментарий #10)
> (In reply to Sergey V Turchin from comment #8)
> > (Ответ для Sergei Naumov на комментарий #2)
> > > https://bugreports.qt.io/browse/QTBUG-82589
> > "Since /lib64 is a symlink to /usr/lib64, the paths /lib64/libQt5Core.so.5
> > an /usr/lib64/libQt5Core.so.5 are both valid."
> > 
> > Возможно, надо в filesystem добавить симлинк /share .
> 
> Как у вас выглядит переменная PATH?

А PATH разве влияет на это?

/opt/cprocsp/bin/amd64:/opt/cprocsp/sbin/amd64:/var/cache/ruby/gemie/bin:/usr/lib/rvm/bin:/opt/cprocsp/bin/amd64:/opt/cprocsp/sbin/amd64:/opt/cprocsp/bin/amd64:/opt/cprocsp/sbin/amd64:/home/serge/bin:/usr/bin:/bin:/usr/local/bin:/usr/lib/kf5/bin:/usr/games:/var/cache/ruby/gemie/bin:/usr/lib/ruby/bin:/usr/bin:/bin

(In reply to Sergei Naumov from comment #0)
> После перехода на filesystem-3.1 перестал запускаться kmail. Видимо, не
> может правильно пути теперь находить:
> 
> [serge@yarilo ~]$ kmail
> Path override failed for key base::DIR_QT_LIBRARY_DATA and path
> '/share/qt5/resources'

Упаковывать /share должно быть не нужно.

Вообще очень интересно, относительно чего здесь пытаются найти этот каталог qt5/resources. Как вариант, относительно /proc/self/exe, поэтому я и задал вопрос про PATH. Если по другому какому-то принципу, то может помочь пересборка пакета.

Qt вычисляет свой prefix неправильно в зависимости от положения libQt5Core.so.5. Я ещё не докопал.

(In reply to Sergei Naumov from comment #12)
> (Ответ для Arseny Maslennikov на комментарий #10)
> > (In reply to Sergey V Turchin from comment #8)
> > > (Ответ для Sergei Naumov на комментарий #2)
> > > > https://bugreports.qt.io/browse/QTBUG-82589
> > > "Since /lib64 is a symlink to /usr/lib64, the paths /lib64/libQt5Core.so.5
> > > an /usr/lib64/libQt5Core.so.5 are both valid."
> > > 
> > > Возможно, надо в filesystem добавить симлинк /share .
> > 
> > Как у вас выглядит переменная PATH?
> 
> А PATH разве влияет на это?

Если /bin был бы перед /usr/bin, то да. Перед отправкой filesystem 3 в сизиф обнаружили, что из-за этого десятки пакетов не могли собраться из исходников. Главным виновником пира духа был cmake, он обнаруживал себя в /bin/cmake и относительно этого пути лез в /lib64/cmake и в /share/cmake.

Проблема в том, что при использовании dladdr() он заполняет Dl_info.dli_fname как /lib64/libQt5Core.so.5, а не как /usr/lib64/libQt5Core.so.5 , из которого и вычисляется Qt-шный prefix.
Получается, надо выбор:
* Добавить симлинк /share
* Возвращать правильное положение библиотеки.

(In reply to Sergei Naumov from comment #0)
> После перехода на filesystem-3.1 перестал запускаться kmail. Видимо, не
> может правильно пути теперь находить:
> 
> [serge@yarilo ~]$ kmail
> Path override failed for key base::DIR_QT_LIBRARY_DATA and path
> '/share/qt5/resources'

Я, когда увидел эту багу, прозевал comment 1, 2 и 3 за огромным description, хотя из этих комментов всё становится ясно; что ув. zerg@ только что и подтвердил.

(In reply to Sergey V Turchin from comment #16)
> Проблема в том, что при использовании dladdr() он заполняет
> Dl_info.dli_fname как /lib64/libQt5Core.so.5, а не как
> /usr/lib64/libQt5Core.so.5 , из которого и вычисляется Qt-шный prefix.
> Получается, надо выбор:
> * Добавить симлинк /share
> * Возвращать правильное положение библиотеки.

Правильное положение библиотек у нас в %_libdir. Видимо, нужно из dynamic linker search path выкинуть /%_lib, но тогда такой dynamic linker станет несовместим с filesystem < 3.

Обращение к /share возникает уже как следствие, так что это точно не вариант. Пойдёт разве что как workaround ручной, чтобы qt5/resources можно сейчас было найти.

(Ответ для Arseny Maslennikov на комментарий #18)
> Обращение к /share возникает уже как следствие, так что это точно не
> вариант.
Да, костыль.

(Ответ для Arseny Maslennikov на комментарий #18)
> (In reply to Sergey V Turchin from comment #16)
> > Проблема в том, что при использовании dladdr() он заполняет
> > Dl_info.dli_fname как /lib64/libQt5Core.so.5, а не как
> > /usr/lib64/libQt5Core.so.5 , из которого и вычисляется Qt-шный prefix.
> > Получается, надо выбор:
> > * Добавить симлинк /share
> > * Возвращать правильное положение библиотеки.
> 
> Правильное положение библиотек у нас в %_libdir. Видимо, нужно из dynamic
> linker search path выкинуть /%_lib, но тогда такой dynamic linker станет
> несовместим с filesystem < 3.
> 

А у него порядок поиска в каталогах поменять нельзя? Чтобы сначала %_libdir, а уже потом %_lib

(In reply to Антон Мидюков from comment #20)
> (Ответ для Arseny Maslennikov на комментарий #18)
> > (In reply to Sergey V Turchin from comment #16)
> > > Проблема в том, что при использовании dladdr() он заполняет
> > > Dl_info.dli_fname как /lib64/libQt5Core.so.5, а не как
> > > /usr/lib64/libQt5Core.so.5 , из которого и вычисляется Qt-шный prefix.
> > > Получается, надо выбор:
> > > * Добавить симлинк /share
> > > * Возвращать правильное положение библиотеки.
> > 
> > Правильное положение библиотек у нас в %_libdir. Видимо, нужно из dynamic
> > linker search path выкинуть /%_lib, но тогда такой dynamic linker станет
> > несовместим с filesystem < 3.
> 
> А у него порядок поиска в каталогах поменять нельзя? Чтобы сначала %_libdir,
> а уже потом %_lib

Это лучше с точки зрения совместимости.
Но тогда возникает вопрос, сломает ли это что-нибудь на unmerged-usr, если такая glibc попадёт в такую систему в результате точечного обновления.

(Ответ для Arseny Maslennikov на комментарий #21)
[...]
> Но тогда возникает вопрос, сломает ли это что-нибудь на unmerged-usr, если
> такая glibc попадёт в такую систему в результате точечного обновления.
При сборке пакета это можно определить.

(Ответ для Arseny Maslennikov на комментарий #21)
> (In reply to Антон Мидюков from comment #20)
> > (Ответ для Arseny Maslennikov на комментарий #18)
> > > (In reply to Sergey V Turchin from comment #16)
> > > > Проблема в том, что при использовании dladdr() он заполняет
> > > > Dl_info.dli_fname как /lib64/libQt5Core.so.5, а не как
> > > > /usr/lib64/libQt5Core.so.5 , из которого и вычисляется Qt-шный prefix.
> > > > Получается, надо выбор:
> > > > * Добавить симлинк /share
> > > > * Возвращать правильное положение библиотеки.
> > > 
> > > Правильное положение библиотек у нас в %_libdir. Видимо, нужно из dynamic
> > > linker search path выкинуть /%_lib, но тогда такой dynamic linker станет
> > > несовместим с filesystem < 3.
> > 
> > А у него порядок поиска в каталогах поменять нельзя? Чтобы сначала %_libdir,
> > а уже потом %_lib
> 
> Это лучше с точки зрения совместимости.
> Но тогда возникает вопрос, сломает ли это что-нибудь на unmerged-usr, если
> такая glibc попадёт в такую систему в результате точечного обновления.

Зависимость на filesystem > 3 сделать?

(In reply to Sergey V Turchin from comment #8)
> Возможно, надо в filesystem добавить симлинк /share .
Надеюсь, это шутка.

(In reply to Arseny Maslennikov from comment #18)
> Правильное положение библиотек у нас в %_libdir. Видимо, нужно из dynamic
> linker search path выкинуть /%_lib, но тогда такой dynamic linker станет
> несовместим с filesystem < 3.
Именно поэтому мы не можем этого сделать.  С другой стороны, я не вижу, чтобы Fedora, например, это делали.  Разберитесь, пожалуйста, как у них работает.

(In reply to Sergei Naumov from comment #2)
> https://bugreports.qt.io/browse/QTBUG-82589
Там есть совершенно резонный комментарий, что дистрибутивам стоит выключать фичу relocatable (https://bugreports.qt.io/browse/QTBUG-82589#comment-500552).

(Ответ для Gleb F-Malinovskiy на комментарий #24)
> > Возможно, надо в filesystem добавить симлинк /share .
> Надеюсь, это шутка.
Шутка, шутка.
Исправьте линкер, чтоб возвращал правильное положение. Это не шутка. ;-)

(Ответ для Gleb F-Malinovskiy на комментарий #24)
> Там есть совершенно резонный комментарий, что дистрибутивам стоит выключать
> фичу relocatable
> (https://bugreports.qt.io/browse/QTBUG-82589#comment-500552).
Да. Ещё и с костылём. https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qtbase-everywhere-src-5.14.2-no_relocatable.patch

Ок, пошёл костылить, а то вас как обычно сложно уговорить. ;-)

(Ответ для Sergey V Turchin на комментарий #26)
> Ок, пошёл костылить, а то вас как обычно сложно уговорить. ;-)
И это тоже стало не так, как раньше, поэтому требует тестирования.

(In reply to Sergey V Turchin from comment #26)
> Ок, пошёл костылить, а то вас как обычно сложно уговорить. ;-)
Сломать системы всем, кто ещё не мигрировал?  Сложно, да. :)

(In reply to Sergey V Turchin from comment #26)
> (Ответ для Gleb F-Malinovskiy на комментарий #24)
> > Там есть совершенно резонный комментарий, что дистрибутивам стоит выключать
> > фичу relocatable
> > (https://bugreports.qt.io/browse/QTBUG-82589#comment-500552).
> Да. Ещё и с костылём.
> https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qtbase-
> everywhere-src-5.14.2-no_relocatable.patch
Патч же по сути просто из-за того, что у них штатный выключатель no_relocatable не работает?  Интересно, почему.

(Ответ для Gleb F-Malinovskiy на комментарий #28)
> > Ок, пошёл костылить, а то вас как обычно сложно уговорить. ;-)
> Сломать системы всем, кто ещё не мигрировал?  Сложно, да. :)
Это напоминает "режим Димы": делать вид, что не понятно, о чём речь.

Я повешу отдельный баг.

Конкретно этот баг: отправил на сборку qt5-base-5.15.13-alt2

(Ответ для Gleb F-Malinovskiy на комментарий #24)
> Там есть совершенно резонный комментарий, что дистрибутивам стоит выключать
> фичу relocatable
> (https://bugreports.qt.io/browse/QTBUG-82589#comment-500552).

Да, там пишут: почините резолвер или используйте костыль из Qt.

https://bugreports.qt.io/browse/QTBUG-82589?focusedId=500548#comment-500548

(In reply to Sergey V Turchin from comment #31)
> https://bugreports.qt.io/browse/QTBUG-82589?focusedId=500548#comment-500548
Там написано «выключить [штатную] фичу qt», которая и не должна была никогда быть включена в дистрибутиве.  Я не понимаю, почему Fedora пришлось выключать этот режим через патч.  Надеюсь, ты разобрался и можешь нам рассказать.

(Ответ для Gleb F-Malinovskiy на комментарий #32)
> > https://bugreports.qt.io/browse/QTBUG-82589?focusedId=500548#comment-500548
> Там написано «выключить [штатную] фичу qt», которая и не должна была никогда
> быть включена в дистрибутиве.
Нет. Там написано, "нештатно выключить фичу qt", которая у всех по умолчанию включена.

>  Я не понимаю, почему Fedora пришлось выключать этот режим через патч.
Не так. Они выключили, но пришлось ещё и патчить.
Судя по вырезанной getExtPrefixFromHostBinDir() с /usr/bin та же самая ерунда.

(In reply to Sergey V Turchin from comment #33)
> (Ответ для Gleb F-Malinovskiy на комментарий #32)
> > > https://bugreports.qt.io/browse/QTBUG-82589?focusedId=500548#comment-500548
> > Там написано «выключить [штатную] фичу qt», которая и не должна была никогда
> > быть включена в дистрибутиве.
> Нет. Там написано, "нештатно выключить фичу qt",
Где?

> которая у всех по умолчанию включена.
Да, по умолчанию включена, но для дистрибутива, очевидно, ошибка её не выключить.

(Ответ для Gleb F-Malinovskiy на комментарий #34)
> > Нет. Там написано, "нештатно выключить фичу qt",
> Где?
Использовать опцию -*no*-feature-relocatable, которая по умолчанию не *no*.
Там много всяких других опций, которые на надо просто так отключать.
И эту ни разу в жизни не надо было.
И в Fedora её сравнительно недавно включили. Видимо, как наступили на те же грабли, только раньше.