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)