Hi Alexey, On Thu, Jul 18, 2013 at 1:10 PM, Alexey Melnikov <alexey.melni...@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.melni...@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ý <ond...@sury.org>
