Library versioning issues.

Library versioning issues.

[Scott Lurndal]

Hi,

  I've a third-party application that's designed to be NUMA aware when
running on a NUMA system, but since this application also runs on non-NUMA
systems and a wide variety of operating systems, they don't link the
application directly with the libnuma shared object.   Instead, they use
dlopen() to open the library at run-time, if it exists.

  The issue is that the application expects the 1.0 interfaces, however the
run time linker dlsym() is returning a function pointer to the _v2 interface
for numa_node_to_cpus_v2, thus the call fails and the application believes
that there is no NUMA configuration available.

  We've fixed this internally (and temporarily) with the patch below,
but would like some guidance as to a longer-term fix that accomodates
applications that use dlopen to access libnuma and preserves versioning
so that older applications will continue to function correctly.

  Perhaps the API for a given function should not change, but rather
new functions should be implemented and the older deprecated?

  thanks,

scott

$ cvs -q diff -ub -r1.1 -r1.2 libnuma.c
Index: libnuma.c
===================================================================
RCS file: /home/slurndal/cvs/opensource/numactl/libnuma.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -b -r1.1 -r1.2
--- libnuma.c   6 Feb 2010 01:18:32 -0000       1.1
+++ libnuma.c   6 Feb 2010 01:23:12 -0000       1.2
@@ -1240,7 +1240,7 @@
        }
        return err;
 }
-__asm__(".symver numa_node_to_cpus_v1,numa_node_to_cpus@libnuma_1.1");
+__asm__(".symver numa_node_to_cpus_v2,numa_node_to_cpus@libnuma_1.1");
 
 /*
  * test whether a node has cpus
@@ -1316,7 +1316,7 @@
        } 
        return err; 
 }
-__asm__(".symver numa_node_to_cpus_v2,numa_node_to_cpus@@libnuma_1.2");
+__asm__(".symver numa_node_to_cpus_v1,numa_node_to_cpus@@libnuma_1.2");
 
 make_internal_alias(numa_node_to_cpus_v1);
 make_internal_alias(numa_node_to_cpus_v2);

Re: Library versioning issues.

[Andi Kleen]

On Tue, Feb 09, 2010 at 01:48:30PM -0800, Scott Lurndal wrote:
> 
> Hi,
> 
>   I've a third-party application that's designed to be NUMA aware when
> running on a NUMA system, but since this application also runs on non-NUMA
> systems and a wide variety of operating systems, they don't link the
> application directly with the libnuma shared object.   Instead, they use
> dlopen() to open the library at run-time, if it exists.

I think you really need to ask this question the dlopen() developers.
I don't think it's a problem that should be somehow kludged around
in libnuma. Simply dlsym() et.al. need a way to specify the expected
version. Otherwise it's a don't do that if it hurts(tm).

-Andi

Re: Library versioning issues II

[Andi Kleen]

As a addendum (after looking at the documentation) it seems like
glibc has already anticipated that problem and 
your user simply needs to switch to dlvsym() and specify the expected
version.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Library versioning issues II

[Scott Lurndal]

On Wed, Feb 10, 2010 at 01:45:12PM +0100, Andi Kleen wrote:
> 
> As a addendum (after looking at the documentation) it seems like
> glibc has already anticipated that problem and 
> your user simply needs to switch to dlvsym() and specify the expected
> version.

Thanks Andi,

   I'll convey this to the vendor.  They may be reluctant to use a
non-posix interface, but c'est la vie.

scott