dladdr() заполняет Dl_info.dli_fname как /lib64/libname.so.1, а не как /usr/lib64/libname.so.1, где она на самом деле находится. Можно проверить ldd на чём угодно. Прошу починить и возвращать правильное положение библиотеки. P.S. Или как обычно будем везде городить костыли вокруг этого?
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.
(Ответ для Dmitry V. Levin на комментарий #1) > meaning of library path names. You mean is no meaning, right?
(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?
(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.
