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
Subject: Re: plruby: rb_iterate symbol clash with libruby.so
In-reply-to: <20181103184259.w5g2quh7fevuny23@alap3.anarazel.de>
References: <4738198.8KVIIDhgEB@nb.usersys.redhat.com>
 <20461.1541269186@sss.pgh.pa.us>
 <20181103183040.jj7gp2zszusnea2d@alap3.anarazel.de>
 <21251.1541270385@sss.pgh.pa.us>
 <20181103184259.w5g2quh7fevuny23@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 03 Nov 2018 11:42:59 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23331.1541273720.1@sss.pgh.pa.us>
Date: Sat, 03 Nov 2018 15:35:20 -0400
Message-ID: <23332.1541273720@sss.pgh.pa.us>
Precedence: bulk

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