Re: Removing link-time cross-module refs in contrib

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