Plugin loading in libsasl

[Ondřej Surý]

Hi Alexey,

On Thu, Jul 18, 2013 at 1:10 PM, Alexey Melnikov
<alexey.melnikov at isode.com>wrote:

>  Hi,
>
>
> On 17/07/2013 14:04, Ondřej Surý wrote:
>
> On Wed, Jul 17, 2013 at 1:02 PM, Alexey Melnikov <
> alexey.melnikov at isode.com> wrote:
>
>> On 16/07/2013 14:23, Ondřej Surý wrote:
>>
>>> Hi,
>>>
>> Hi Ondřej,
>>
>>  I have realized one quite serious problem in plugin loading with recent
>>> SONAME bump.
>>>
>>> The plugins are versioned, but the library ignores that and looks for
>>> .so files in the plugins directory.
>>>
>>> This basically prevents the gradual transitioning from one SONAME to
>>> another, since at one point in time you have to replace the plugins with
>>> one version or another.
>>>
>>> I would propose to change the mechanism to look for:
>>>
>>> .so.<SONAME>
>>>
>>  How can libsasl library know expected <SONAME> information?
>
>
>  I expect that one should be able to compute it at compile time from the
> info passed to libtool.
>
>
> So you are suggesting that this information is hardcoded into libsasl
> during build time?
>
> How would this work with third party plugins (which don't have to use the
> same <SONAME>)?
>
> There are also some platforms which might not be generating .<SONAME> at
> all. The code needs to be generic to handle these as well.
>

I am just stating that it's very hard to bump SONAME for libsasl when you
have unversioned plugins in the system.

Maybe somebody else will have a better idea how to handle the transitions
when you have some programs compiled with libsasl.so.2 and some with
libsasl.so.3, because it's virtually impossible to do the change at the one
point of the time for all packages using libsasl.

Ondrej
-- 
Ondřej Surý <ondrej at sury.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20130724/303c7d41/attachment.html