Markus Heinz wrote in <5bafe02fa7f810b05876d5b2a14c5994.squirrel@webmail.tu-dortmund.de>: |> On 14.08.2021 00:00, Markus Heinz wrote: |>>Does someone have an idea how to fix this? |> |> I do have an idea how to fix this cosmetic problem: |> sudo echo "/usr/lib/perl5/5.32/linux-thread-multi/CORE" > |> /etc/ld.so.conf.d/perl.conf | |I can confirm that this file resolves the issue. | |> It would be nice if this could be handled in core/perl directly instead, |> so I hope that Matt and/or Jürgen could add it accordingly. | |I'd appreciate it too if the core/perl port gets updated accordingly. But normal that is not, ne? Placing such libraries in a generic public library search path, that is. Where would that end? Normally one uses a script like krb5-config, pkgconfig or how those are called, or whatever, when you have such. No? I just wonder why postgres does not do that automatically, when it links against perl. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Hello. Markus Heinz wrote in <20210814234904.0210ffda@computer5>: |On Sat, 14 Aug 2021 22:57:33 +0200 |Steffen Nurpmeso <steffen@sdaoden.eu> wrote: | |> But normal that is not, ne? Placing such libraries in a generic |> public library search path, that is. Where would that end? |> |> Normally one uses a script like krb5-config, pkgconfig or how |> those are called, or whatever, when you have such. No? |> I just wonder why postgres does not do that automatically, when it |> links against perl. | |I think there is a difference between compile time linking and run time |linking: | |During compile time of the postgresql build the "libperl.so" file had |been found, otherwise the build would have failed as it is built with |perl support explicitly enabled in the Pkgfile. Yes, of course. Yes. For the runtime linker you normally add -Wl,-rpath=PATH (on Linux ..etc..) when you link against libraries in non-common locations, and in output of "readelf -d" you then see this like 0x000000000000001d (RUNPATH) Library runpath: [/usr/local/lib] The manual of ld(1) states If -rpath is not used when linking an ELF executable, the contents of the environment variable "LD_RUN_PATH" will be used if it is defined. |But during run time of the "revdep" utility the "libperl.so" file cannot |be found as it is located in a non standard location which is not |configured to be searched for shared libraries by default. So for this to work -Wl,-rpath=PATH has to be passed. I only wondered why the build system of postgresql does not do that, likely a bug. |Actually I do not know if the perl related functionality in postgresql |is affected by this or not as I do not use the perl related |functionality. I assume it is a kind of plugin language for writing |stored procedures or something similar. Surely. (Have luckily not looked into such for a very very long time.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On 15.08.2021 12:31, Alan Mizrahi wrote:

It would be better to fix this by using -rpath when building, or with the patchelf program after building.

Cheers Alan, I just added a patch arch was using for rpath and pushed it to contrib. Best regards, Tim