Re: plruby: rb_iterate symbol clash with libruby.so
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Pavel Raiskup <praiskup@redhat.com>,
PostgreSQL Hacker <pgsql-hackers@postgresql.org>, devrim@gunduz.org
Date: 2018-11-03T19:35:20Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2018-11-03 14:39:45 -0400, Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: >>> ISTM this specific case we could solve the issue by opening plruby.so / >>> extension sos with RTLD_DEEPBIND. That doesn't work if ruby extensions >>> that are loaded later use rb_iterate, but should work for the case above. >> Doesn't work on non-glibc platforms, though. > Yea, but I'm not sure there's anything portable to do about such cases :/ The portable answer is to rename to avoid the symbol conflict. >>> I don't mind the precedent that much, but isn't that also not unlikely >>> to break other extensions that use those functions? >> I rather doubt there are any. Also, if there are, the RTLD_DEEPBIND >> solution would break them too, no? > Why would it break? Deepbind just means the to-be-opened .so is put > first in the search path, if there's no match it'll still look in other > sos. Yeah, but once plruby is loaded, any subsequently loaded .so has got two possible ways to resolve rb_iterate. No matter what we do, the behavior will be wrong for some of them. regards, tom lane
Commits
-
Rename rbtree.c functions to use "rbt" prefix not "rb" prefix.
- b2e754c14e27 10.7 landed
- 1f28ec6be270 11.1 landed
- 003c68a3b45d 12.0 landed