Peter Eisentraut <pete...@gmx.net> writes:
> On 4/26/15 12:36 PM, Tom Lane wrote:
>> I don't know why this patch is fooling around with compile/link flags,
>> but it's broken at least prairiedog
> The addition of the link flag -undefined dynamic_lookup is so that
> plugins can refer to symbols from other plugins. This is how other
> platforms work by default, and it is standard for OS X in GNU libtool
> and many other projects. I'm confused why prairiedog is complaining
> about that.
We could look into a fix for prairiedog's situation, but TBH I think that
that is going in 100% the wrong direction. I'm pretty desperately unhappy
with the design choice you've made here, for two reasons:
1. Preventing undefined-symbol errors at link time might be standard
according to some platforms, but it is not the universal default, and
I think there is no very good reason to assume that it is possible
everywhere. So I'm afraid that prairiedog is just the canary in the coal
mine, warning us about portability problems we're going to have with
other non-mainstream platforms not represented in the buildfarm.
2. Preventing undefined-symbol errors at link time will hide actual coding
errors, not only the intended cross-plugin reference cases. We have
repeatedly seen the buildfarm members that complain about this find actual
bugs that were missed on laxer platforms. Therefore I think that this
approach is going to lead to masking bugs that we'll find only by much
more expensive/painful means than noticing a buildfarm failure.
Surely there are other ways to deal with this requirement that don't
require forcing undefined symbols to be treated as valid. For instance,
our existing find_rendezvous_variable() infrastructure might offer a
usable solution for passing a function pointer from plugin A to plugin B.
Indeed, that's pretty much what it was invented for.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
