Bug 473072 - Function signature of numa_node_to_cpus changed, but .so version was not bumped
Summary: Function signature of numa_node_to_cpus changed, but .so version was not bumped
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: numactl
Version: 10
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-26 13:55 UTC by Chris Lalancette
Modified: 2009-04-16 10:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-16 10:55:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Chris Lalancette 2008-11-26 13:55:49 UTC
Description of problem:
It seems that between F-9 and F-10, the function signature of (at least) numa_node_to_cpus() was changed from:

int numa_node_to_cpus(int node, unsigned long *buffer, int buffer_len);

to:

int numa_node_to_cpus(int, struct bitmask *);

However, the .so version of the numactl library was not bumped, which means we can't properly add the BuildRequires to other packages (like libvirt, which is suffering a build issue because of this issue: https://bugzilla.redhat.com/show_bug.cgi?id=473070).  It seems like if the interface changes, the .so version should also be changed to reflect that.

Comment 1 Neil Horman 2008-11-26 18:14:59 UTC
yeah.  Ideally I should be maintaining backward compatibilty, but there was no clear way to do it safely here.    I'm building a scratch package with a fix for this.  Please verify that it solves your problems, and I'll commit it to F-10 and rawhide (and likely send it upstream).  The build is here:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=953426

Thanks!

Comment 2 Neil Horman 2008-11-26 18:22:38 UTC
sorry, minor error, this is the build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=953436

Comment 3 Daniel Berrangé 2008-11-27 13:15:40 UTC
Actually the libnuma.so *does* have ABI compatability. They appear to be doing it with versioned linker script black magic. So no change is required.

Comment 4 Daniel Berrangé 2008-11-27 13:19:22 UTC
As a point of reference, as well as ABI compatability, they also provide source level compatability - you merely need to add

-DNUMA_VERSION1_COMPATIBILITY

to your compile flags before including numa.h

So, recommend *not* making an soname change, and close this NOTABUG

Comment 5 Neil Horman 2009-04-16 10:55:36 UTC
yeah, i agree


Note You need to log in before you can comment on or make changes to this bug.