On 2016-10-03 14:49:20 -0400, Tom Lane wrote:
> > On 2016-10-03 12:29:18 -0400, Tom Lane wrote:
> >> The patch seems pretty successful in terms of being noninvasive to
> >> the code. I think the major objection to it would be that we no
> >> longer have any direct compiler-verified connection between the
> >> signatures of the called functions in hstore/plpython and what
> >> hstore_plpython thinks they are.
>
> > We could instead add a AssertVariableIsOfType(), besides the library
> > lookup maybe?
>
> Hmm ... had not occurred to me that that might work on a function name.
> I'll go try it.
I'm pretty sure it does, I've used it for that in the past.
> Andres Freund <andres@anarazel.de> writes:
> >> If we were to push forward with this idea, the remaining work
> >> would be to fix the other two contrib transform modules similarly,
> >> after which I would want to revert the changes in commit cac765820
> >> and later that suppressed linker errors for unresolved symbols in
> >> contrib links. The possibility of getting back that error detection
> >> is actually the main motivation for this IMO.
>
> > That'd be rather neat.
>
> I experimented with that aspect a bit today. For macOS it's sufficient
> to remove the "-Wl,-undefined,dynamic_lookup" linker flag that cac765820
> added. However, ignoring unresolved symbols in shlibs is the default
> on Linux, and while you can make it throw errors, that just leads to
> errors for all the references into the core backend. Not very helpful.
> AFAICS, GNU ld lacks any equivalent to macOS' -bundle_loader switch,
> which is what we'd need to make this usable.
Hm. I wonder if it's actually possible to link against the main backend,
when compiling as a position-independent-executable...
> A workable compromise for Linux might be to enable -Wl,-z,now which
> changes unresolved symbol resolution from lazy to on-load. That would
> at least guarantee that any testing whatsoever would detect incorrect
> references, even if the bad call wasn't exercised.
Hm, I think that's the default already no? At least linux has
#define pg_dlopen(f) dlopen((f), RTLD_NOW | RTLD_GLOBAL)
which should trigger that behaviour, and I do remember seing errors
because of non-exercised function and variable references.
Regards,
Andres
