Bug 50162

Summary:	Dl_info.dli_fname is out of sync with usrmerge
Product:	Sisyphus	Reporter:	Sergey V Turchin <zerg>
Component:	glibc	Assignee:	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.