On 2016-10-02 17:59:47 -0400, Tom Lane wrote: > I've found that the Linux '-l:hstore.so' solution works on HPUX as well, > at least to the extent of being able to run LOAD. However, it doesn't > seem to be possible to make it work on macOS, which has a hard distinction > between "loadable modules" and "shared libraries". Our extensions are > the former, which means that e.g. hstore.so is not a shlib and the linker > will refuse to consider it as a linkable library. I tried converting > them to true shlibs, which is just a matter of changing "-bundle" to > "-dynamiclib" in the link command and dropping "-bundle_loader postgres" > because that's not accepted with "-dynamiclib". That works about 90%, > but I found that plpython failed its regression test for a very scary > reason: there's a "hash_search()" somewhere in libc on this platform > and the linker was preferentially resolving plpython's call to that > rather than to the one in Postgres. I don't think we want to risk > that sort of platform dependency :-(
ISTM that that's a risk independent of this specific issue? On other platforms, I mean? > So now I'm thinking you're right, it'd be better to have some solution > whereby dfmgr.c knows about cross-module dependencies and loads the > dependencies first. Not sure how to approach that. The extension > "requires" mechanism is tantalizingly close to providing the data > we need, but dfmgr.c doesn't know about that, and there's no concept > of a reverse mapping from .so names to extensions anyway. One, kind of extreme, way to get there would be to resolve the hstore symbols hstore_plpython needs with load_external_function, during _PG_init(). Most of these files don't actually depend on a large number of symbols, so that should actually be doable. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
