#50162 – Dl_info.dli_fname is out of sync with usrmerge

Bug 50162 - Dl_info.dli_fname is out of sync with usrmerge

Summary: Dl_info.dli_fname is out of sync with usrmerge

Status:	CLOSED NOTABUG

Alias:	None

Product:	Sisyphus
Classification:	Development
Component:	glibc (show other bugs)
Version:	unstable
Hardware:	x86_64 Linux

Importance:	P5 normal
Assignee:	Gleb F-Malinovskiy
QA Contact:	qa-sisyphus

URL:
Keywords:

Depends on:
Blocks:	50121
	Show dependency tree

Reported:	2024-04-25 10:37 MSK by Sergey V Turchin
Modified:	2024-10-15 17:53 MSK (History)
CC List:	5 users (show)

See Also:	50136

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

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.