Re: [hwloc-devel] 1.1 .so version number
Le 09/11/2010 18:49, Samuel Thibault a écrit : > That is not a problem here. The attr field of hwloc_obj will be NULL, > that's all, the application won't ever read it anyway. > We will see segfaults if applications were looking at machine->attr without checking that it's non-NULL. It's a buggy behavior (but may not be that well documented :)) and there are very likely a single user of these machine attributes anyway (and I am going to fix it now :)). Brice
Re: [hwloc-devel] 1.1 .so version number
On Nov 9, 2010, at 12:49 PM, Samuel Thibault wrote: >> But the object structure has been extended, cache attributes were >> extended, > > Extension is not a problem, provided that offsets are still the same > (i.e. the old C structure appears first in the new C structure) > >> machine attributes were removed. > > That is not a problem here. The attr field of hwloc_obj will be NULL, > that's all, the application won't ever read it anyway. > > I don't see anything else that we removed (that's why you have added > cpuset aliases actually). Could you try it? I.e.: - install 1.0.2 (or, better: 1.0.3rc) - compile and run a trivial hwloc app against 1.0.x - download and extract 1.1rc2 - change VERSION to be 1:0:1 - build and install 1.1rc2 over the 1.0.x install - run the same trivial hwloc app against the new library without recompiling/relinking it Does it work? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] 1.1 .so version number
Brice Goglin, le Mon 08 Nov 2010 16:57:44 +0100, a écrit : > Le 08/11/2010 15:38, Jeff Squyres a écrit : > > Short version: > > -- > > > > I have not looked closely -- I *think* APIs have been added and changed > > since v1.0. As such, I *think* the libtool .so version number for 1.1 > > should be 1:0:0. > > > > I don't think any function behavior changed. I don't think either. > But the object structure has been extended, cache attributes were > extended, Extension is not a problem, provided that offsets are still the same (i.e. the old C structure appears first in the new C structure) > machine attributes were removed. That is not a problem here. The attr field of hwloc_obj will be NULL, that's all, the application won't ever read it anyway. I don't see anything else that we removed (that's why you have added cpuset aliases actually). Samuel
Re: [hwloc-devel] 1.1 .so version number
Jeff Squyres, le Mon 08 Nov 2010 15:38:31 +0100, a écrit : > The last one is what I'm not sure about, but what I'm inferring from Samuel's > statement about "API breaks". Actually you can have an API break without an ABI break. Here, old applications should work fine. They'll just not be able to reach the DMI strings, as they're now in "infos". But they won't crash since attrs will just be empty. So I believe we can use 1:0:1. That's why we have kept aliases in src/cpuset.c for, actually. Samuel
Re: [hwloc-devel] 1.1 .so version number
Le 08/11/2010 15:38, Jeff Squyres a écrit : > Short version: > -- > > I have not looked closely -- I *think* APIs have been added and changed since > v1.0. As such, I *think* the libtool .so version number for 1.1 should be > 1:0:0. > I don't think any function behavior changed. But the object structure has been extended, cache attributes were extended, machine attributes were removed. > Can someone verify? > > Note that this means that applications linked against hwloc 1.0.x will not be > able to upgrade to hwloc 1.1 without a recompile/relink. > It looks ok. > More details: > - > > If we assume the last version number of the 1.0 series will be 0:2:0, per > Libtool .so versioning guidelines here: > > http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning > > and > > http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info > > The following rules apply: > > - If the library source code has changed at all since the last update, then > increment revision (‘c :r :a ’ becomes ‘c :r + 1:a ’). > --> takes us to 0:3:0 > > - If any interfaces have been added, removed, or changed since the last > update, increment current, and set revision to 0. > --> takes us to 1:0:0 > > - If any interfaces have been added since the last public release, then > increment age. > --> takes us to 1:0:1 > > - If any interfaces have been removed or changed since the last public > release, then set > age to 0. > --> takes us back to 1:0:0 > Looks ok too. Brice
[hwloc-devel] 1.1 .so version number
Short version: -- I have not looked closely -- I *think* APIs have been added and changed since v1.0. As such, I *think* the libtool .so version number for 1.1 should be 1:0:0. Can someone verify? Note that this means that applications linked against hwloc 1.0.x will not be able to upgrade to hwloc 1.1 without a recompile/relink. More details: - If we assume the last version number of the 1.0 series will be 0:2:0, per Libtool .so versioning guidelines here: http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning and http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info The following rules apply: - If the library source code has changed at all since the last update, then increment revision (‘c :r :a ’ becomes ‘c :r + 1:a ’). --> takes us to 0:3:0 - If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0. --> takes us to 1:0:0 - If any interfaces have been added since the last public release, then increment age. --> takes us to 1:0:1 - If any interfaces have been removed or changed since the last public release, then set age to 0. --> takes us back to 1:0:0 The last one is what I'm not sure about, but what I'm inferring from Samuel's statement about "API breaks". -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
