Bug 473072 - Function signature of numa_node_to_cpus changed, but .so version was not bumped
Function signature of numa_node_to_cpus changed, but .so version was not bumped
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: numactl (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-26 08:55 EST by Chris Lalancette
Modified: 2009-04-16 06:55 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-16 06:55:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Lalancette 2008-11-26 08:55:49 EST
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 13:14:59 EST
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 13:22:38 EST
sorry, minor error, this is the build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=953436
Comment 3 Daniel Berrange 2008-11-27 08:15:40 EST
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 Berrange 2008-11-27 08:19:22 EST
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 06:55:36 EDT
yeah, i agree

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