On Tue, Apr 15, 2008 at 01:35:42AM +0200, Andi Kleen wrote: > Cliff Wickman wrote: > > Per Andi's post, the current version of numactl/libnuma changes the > > application programming interface, so it should be bumped to version 2. > > (the symbol versioning preserves the version 1 ABI) > > > > And he also suggested we supply some compatibility wrappers with a compat > > define for old programs. > > > > This patch provides numacompat1.h and additions to numa.h, which provide > > source code compatibility to libnuma version 1. > > > > Makefile is changed to install as version 2, and install numacompat1.h > > Can you change numa.h to include numacompat1.h when some define > is set? This way Makefiles can be easier changed. I run into a problem here. If numa.h includes numacompat1.h then you get conflicts with other include files that appear after numa.h in some source code (like numactl.c for example). I don't see an easy solution to that -- suggestions welcome. It might not be as clean to add the #include <numacompat1.h> to a .c as to add a -D to a Makefile, but it's pretty easy don't you think? > > And are you sure the symbol versions still work for old binaries when > you install as version 2? Normally with symbol versions the major number > of the .so should not change AFAIK, otherwise the ld.so won't find them > and all the version numbers only be defined in the script. Agreed. I guess the convention of incrementing .so.1 to .so.2 doesn't make sense with symbol versioning. I'll remove that. > > -Andi -Cliff -- Cliff Wickman Silicon Graphics, Inc. cpw@xxxxxxx (651) 683-3824 -- To unsubscribe from this list: send the line "unsubscribe linux-numa" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
