On Tue, Apr 04, 2017 at 09:42:47AM +0200, Michal Privoznik wrote:
On 04/04/2017 09:27 AM, Jiri Denemark wrote:
> On Tue, Apr 04, 2017 at 09:24:41 +0200, Michal Privoznik wrote:
> > The symbol was introduced in the 3.2.0 release (bb09798fbeb5f)
> > and not 3.1.0 release as its current placement in the file
> > suggests.
> >
> > Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
> > ---
> > src/libvirt_public.syms | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
> > index 428cf2e..37a8a18 100644
> > --- a/src/libvirt_public.syms
> > +++ b/src/libvirt_public.syms
> > @@ -755,8 +755,12 @@ LIBVIRT_3.0.0 {
> >
> > LIBVIRT_3.1.0 {
> > global:
> > - virDomainSetBlockThreshold;
> > virDomainSetVcpu;
> > } LIBVIRT_3.0.0;
> >
> > +LIBVIRT_3.2.0 {
> > + global:
> > + virDomainSetBlockThreshold;
> > +} LIBVIRT_3.1.0;
> > +
> > # .... define new API here using predicted next version number ....
>
> Oh, this is unfortunate. But doesn't this change break ABI?
Well, the change I'm referring to in the commit message broke ABI in the
first place. This will break ABI only for apps linked with 3.2.0 release and
un-break apps linked with every other release.
No, the original change doesn't break ABI at all. It merely added a new
symbol to the existing ABI. This means that applications which used the
new API would build, link & run just fine - they'll simply not get an
automatic dependancy on libvirt 3.2.0 added to the RPM deps. By contrast,
changing the version now, will definitely break ABI, since any apps which
linked to libvirt 3.2.0 using this API will have unresolveable symbols at
link load time.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://entangle-photo.org -o-
http://search.cpan.org/~danberr/ :|