Bug 50162

Summary: Dl_info.dli_fname is out of sync with usrmerge
Product: Sisyphus Reporter: Sergey V Turchin <zerg>
Component: glibcAssignee: placeholder <placeholder>
Status: CLOSED NOTABUG QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: antohami, arseny, glebfm, iv, ldv, placeholder
Version: unstable   
Hardware: x86_64   
OS: Linux   
See Also: https://bugzilla.altlinux.org/show_bug.cgi?id=50136
Bug Depends on:    
Bug Blocks: 50121    

Description Sergey V Turchin 2024-04-25 10:37:01 MSK
dladdr() заполняет Dl_info.dli_fname как /lib64/libname.so.1, а не как /usr/lib64/libname.so.1, где она на самом деле находится.

Можно проверить ldd на чём угодно.

Прошу починить и возвращать правильное положение библиотеки.

P.S.
Или как обычно будем везде городить костыли вокруг этого?
Comment 1 Dmitry V. Levin 2024-04-27 01:15:13 MSK
ldconfig adds SLIBDIR before LIBDIR to the list of the standard search paths.
Apparently, after usrmerge this causes issues with some buggy software that has incorrect assumptions about the meaning of library path names.
Comment 2 Sergey V Turchin 2024-04-27 10:23:27 MSK
(Ответ для Dmitry V. Levin на комментарий #1)
> meaning of library path names.
You mean is no meaning, right?
Comment 3 Arseny Maslennikov 2024-04-27 13:12:34 MSK
(In reply to Dmitry V. Levin from comment #1)
> ldconfig adds SLIBDIR before LIBDIR to the list of the standard search paths.
> Apparently, after usrmerge this causes issues with some buggy software that
> has incorrect assumptions about the meaning of library path names.

Could you please clarify for the wider audience, what exactly is this meaning of library path names? Or give a hyperlink, so the curious reader can RTFM. :)

Specifically, do you mean software should make no assumptions about the environment based on library path names?
Comment 4 Gleb F-Malinovskiy 2024-04-27 15:25:51 MSK
(In reply to Arseny Maslennikov from comment #3)
> (In reply to Dmitry V. Levin from comment #1)
> > ldconfig adds SLIBDIR before LIBDIR to the list of the standard search paths.
> > Apparently, after usrmerge this causes issues with some buggy software that
> > has incorrect assumptions about the meaning of library path names.
> 
> Could you please clarify for the wider audience, what exactly is this
> meaning of library path names? Or give a hyperlink, so the curious reader
> can RTFM. :)
It's simply the path where the loader found the library, nothing more.

> Specifically, do you mean software should make no assumptions about the
> environment based on library path names?
I personally don't think so, but when it comes to software built specifically for use in the distribution's environment, it's *much safer* to assume that the data is located under /usr/share rather than assume <library basename>/../share.

In the case of Qt, this assumption is primarily made to support relocation of Qt libraries.  Qt, when built with the relocatable feature, can be installed under directories like /opt or within the user's personal environment under /home.  As I stated above, it doesn't make any sense if Qt is specifically built for use in the distribution environment.