Re: plruby: rb_iterate symbol clash with libruby.so

Pavel Raiskup <praiskup(at)redhat(dot)com> writes:
> Hi, I'm curious how it worked before (seems like the function is defined
> in both PostgreSQL and Ruby projects for quite some time) - but I recently
> came across this situation:
> - /bin/postgres is build-time linked with 'ld -E'
> - /bin/postgres dlopen()s plruby.so
> - plruby.so calls rb_iterate, but linker prefers rb_iterate defined in
> /bin/postgres, instead of (the wanted one) rb_iterate from libruby.so
> This means an ugly PG server crash. I'm curious what to do with this;
> ideally it would be solvable from plruby.so itself, but there doesn't seem
> to be nice solution (one could do some hacks with dlopen('libruby.so')).

Bleah.

We recently noticed that using a --version-script symbol filter on shared
libraries fixes some cases of this problem, because a non-exported symbol
will be preferentially resolved inside the library. I guess that's of no
use for this particular case though, since evidently Ruby has to export
its rb_iterate for Ruby extensions to use.

> Is it realistic we could rename red-black tree methods from 'rb_*' to e.g.
> 'rbt_*' to avoid this clash?

That's not terribly appetizing, because it essentially means we're giving
Ruby (and potentially every other library on the planet) veto power over
our function namespace. That does not scale, especially not when the
feedback loop has a time constant measured in years :-(

I don't have a huge objection to renaming the rbtree functions, other
than the precedent it sets ...

regards, tom lane