Re: Using RTLD_DEEPBIND to handle symbol conflicts in loaded libraries

On Wed, Nov 26, 2014 at 01:34:18PM +0200, Ants Aasma wrote:
> glibc-2.3.4+ has a flag called RTLD_DEEPBIND for dlopen that prefers
> symbols loaded by the library to those provided by the caller. Using
> this flag fixes my issue, PostgreSQL gets the ldap functions from
> libldap, Oracle client gets them from whatever it links to. Both work
> fine.
>
> Attached is a patch that enables this flag on Linux when available.
> This specific case could also be fixed by rewriting oracle_fdw to use
> dlopen for libclntsh.so and pass this flag, but I think it would be
> better to enable it for all PostgreSQL loaded extension modules. I
> can't think of a sane use case where it would be correct to prefer
> PostgreSQL loaded symbols to those the library was actually linked
> against.
>
> Does anybody know of a case where this flag wouldn't be a good idea?

There's a meta-downside that any bug the flag prevents will still exist on
non-glibc targets, and that's the primary reason not to make this change in
core PostgreSQL. Most hackers use GNU/Linux as a primary development
platform, so RTLD_DEEPBIND would delay discovery of still-present bugs.

Standard POSIX symbol resolution has some advantages over RTLD_DEEPBIND. Any
given program has at most one global symbol called "malloc", and so-named
symbols usually get away with assuming they own the brk() space. LD_PRELOAD
can overload any global symbol. Those points by themselves would not stop me
from using RTLD_DEEPBIND in specific cases like oracle_fdw, though.

> Are there any similar options for other platforms? Alternatively, does
> anyone know of linker flags that would give a similar effect?

It has some overlap with the -Bsymbolic linker option.