> On Oct 29, 2024, at 10:55 AM, David E. Wheeler <da...@justatheory.com> wrote: > >>> Relative rpaths as I have seen them are relative to the executable or >>> library in which they are defined (as far as I know, I’m not a dylib expert >>> by any stretch). The implication is that extension.so >>> <http://extension.so/> could have an rpath=. and dependent dylibs sitting >>> next to it. This is how, for example, cmake out-of-tree builds can run >>> tests against the newly built library before it’s installed,.. the test >>> execs have an rpath of ../lib on them. >> >> Oh that’s super interesting. Will be worth trying. I was hoping to avoid >> having to set rpath in every extension, though, but maybe that’d be the way >> forward. >> >> The issue, though, is a tree of dependencies. Would you really want to >> include both libcurl and OpenSSL in a pgsql-http binary distribution package >> --- especially since Postgres itself will be using its own OpenSSL package? >> To Christophe’s point, I think we might want to delegate the provisioning of >> dependency DSOs to the system package manager.
Trouble is, the extension and the library it depends upon are quite tightly linked at build time. During build, the extension will be looking at the library version to determine what features to enable, and to know what functions it can call. Frequently a whole extra SQL function might depend on a new feature in the library, and be #ifdef’ed out if the library is too old. An extension built against the latest library, but installed against an earlier one will error out quite quickly when it finds it has symbols that cannot be resolved in the library it has dylinked to. At that point you’re better off distributing the extension via the packaging system, where you know that all the dependency versions line up correctly. ATB, P
