boost dll versions
I think it is a bit unfortunate that we don't have a system to determine whether boost updates break existing api's. The usual process is that, for example, suppose we have libboost.so.1.33.0 Let's assign this soname libboost.so.1. Then a symlink is created libboost.so.1 -> libboost.so.1.33.0. Now if a bugfix comes out that does not change the api, be can have libboost.so.1.33.1, which also has soname libboost.so.1, and then symlink: libboost.so.1 -> libboost.so.1.33.1 OK, so that's the background. AFAICT, we (boost) don't have any way to tell if a new release breaks existing api, and whether to up the version. I think that is unfortunate. I don't really know what to do about it, though.
Neal Becker wrote:
I think it is a bit unfortunate that we don't have a system to determine whether boost updates break existing api's.
I've always been under the assumption that 1.x to 1.y release will change the binary API, and that 1.33.x to 1.33.y will not.
The usual process is that, for example, suppose we have
libboost.so.1.33.0
Let's assign this soname libboost.so.1. Then a symlink is created
libboost.so.1 -> libboost.so.1.33.0.
Now if a bugfix comes out that does not change the api, be can have
libboost.so.1.33.1, which also has soname libboost.so.1, and then symlink:
libboost.so.1 -> libboost.so.1.33.1
Is that what the RPM does? It's not what the regular build does.
OK, so that's the background. AFAICT, we (boost) don't have any way to tell if a new release breaks existing api, and whether to up the version. I think that is unfortunate. I don't really know what to do about it, though.
Perhaps the misunderstanding is that we consider the "version" to be 1.33 in this case. So instead of doing above you would do: libboost.so.1.33.0 libboost.so.1.33 --> libboost.so.1.33.0 And the new patch revision would be: libboost.so.1.33.1 libboost.so.1.33 --> libboost.so.1.33.1 Basically there's no "1" version, ever. If that's not what the RedHat RPMs do I would say that's a mistake and should be corrected. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote: [...] So, if I understand you correctly, you say soname for boost-1.33.0 should be 1.33? It isn't AFAICT. objdump -p /usr/lib64/libboost_python.so.1.33.0 | awk '/SONAME/ {print $2}' libboost_python.so.1.33.0 I agree with you - it _should_ be 1.33, but it doesn't look like it is set correctly.
Neal Becker wrote:
Rene Rivera wrote:
[...]
So, if I understand you correctly, you say soname for boost-1.33.0 should be 1.33?
Not exactly what I said :-) I meant that at _minimum_ it should be "1.33", but that I preferred it to be "1.33.0" as we don't explicitly make *any* version binary compatability assurances.
It isn't AFAICT.
objdump -p /usr/lib64/libboost_python.so.1.33.0 | awk '/SONAME/ {print $2}' libboost_python.so.1.33.0
Since I implemented the SONAME stuff I did what I preferred ;-)
I agree with you - it _should_ be 1.33, but it doesn't look like it is set correctly.
The big question... Are Boost developers willing to make the guarantee that patch versions, i.e. 1.33.0 to 1.33.1, will be binary compatible? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
From: Rene Rivera <grafik.list@redshift-software.com>
The big question... Are Boost developers willing to make the guarantee that patch versions, i.e. 1.33.0 to 1.33.1, will be binary compatible?
There are only a few compiled Boost libraries, so the question only applies to them, right? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: Rene Rivera <grafik.list@redshift-software.com>
The big question... Are Boost developers willing to make the guarantee that patch versions, i.e. 1.33.0 to 1.33.1, will be binary compatible?
There are only a few compiled Boost libraries, so the question only applies to them, right?
I believe that because the non-header-only libraries depend on many of the header-only libraries, even if the code of the non-header-only libraries does not change at all, changes in those header-only libraries could result in binary incompatibility. I think, therefore, that retaining binary compatibility between versions will be nearly impossible. -- Jeremy Maitin-Shepard
Jeremy Maitin-Shepard wrote:
Rob Stewart <stewart@sig.com> writes:
From: Rene Rivera <grafik.list@redshift-software.com>
The big question... Are Boost developers willing to make the guarantee that patch versions, i.e. 1.33.0 to 1.33.1, will be binary compatible?
There are only a few compiled Boost libraries, so the question only applies to them, right?
I believe that because the non-header-only libraries depend on many of the header-only libraries, even if the code of the non-header-only libraries does not change at all, changes in those header-only libraries could result in binary incompatibility. I think, therefore, that retaining binary compatibility between versions will be nearly impossible.
Well, you can hide all use of other libraries under pimpl, and then you'll have to worry only about classes that are exponsed via public interfaces -- which should be few. - Volodya
Jeremy Maitin-Shepard wrote:
Rob Stewart <stewart@sig.com> writes:
From: Rene Rivera <grafik.list@redshift-software.com>
The big question... Are Boost developers willing to make the guarantee that patch versions, i.e. 1.33.0 to 1.33.1, will be binary compatible?
There are only a few compiled Boost libraries, so the question only applies to them, right?
I believe that because the non-header-only libraries depend on many of the header-only libraries, even if the code of the non-header-only libraries does not change at all, changes in those header-only libraries could result in binary incompatibility. I think, therefore, that retaining binary compatibility between versions will be nearly impossible.
The best I can suggest is that we arrange to run regression tests using updated headers but with previous dlls, and see if they pass. Would that be difficult to implement?
Rob Stewart <stewart@sig.com> writes:
From: Rene Rivera <grafik.list@redshift-software.com>
The big question... Are Boost developers willing to make the guarantee that patch versions, i.e. 1.33.0 to 1.33.1, will be binary compatible?
There are only a few compiled Boost libraries, so the question only applies to them, right?
That's an interesting distinction to make. We'd only be guaranteeing that you can drop in the new library objects and not, if you have a published API using Boost, that your own binary interface will remain when you upgrade to the patch version of Boost. I'm not sure we want to say that, but if we do it that way we'd better be *very* clear about it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Neal Becker wrote:
I think it is a bit unfortunate that we don't have a system to determine whether boost updates break existing api's. The usual process is that, for example, suppose we have
libboost.so.1.33.0
Let's assign this soname libboost.so.1. Then a symlink is created
libboost.so.1 -> libboost.so.1.33.0.
Now if a bugfix comes out that does not change the api, be can have
libboost.so.1.33.1, which also has soname libboost.so.1, and then symlink:
libboost.so.1 -> libboost.so.1.33.1
OK, so that's the background. AFAICT, we (boost) don't have any way to tell if a new release breaks existing api, and whether to up the version. I think that is unfortunate. I don't really know what to do about it, though.
Shared libraries are typically versioned as <major>.<minor>.<patch>, and the semantics of these are tied to ABI/API compatibility. That is, every ABI change has to be accounted for by an increment in the major version number. That is how these links above as well as the embedded sonames are supposed to work. Boost right now seems to equate library versions and release versions, which certainly adds to the confusion. Then, the name '1.33' somehow suggests two levels of versions, while really there is only one (by the way: why do you carry the '1.' around ? Do you expect a 'release 2' at some point ? If so, in what way would such a release be different from an upgrade from 1.32 to 1.33, say ?) Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
Boost right now seems to equate library versions and release versions, which certainly adds to the confusion.
I don't see why? Seems to me keeping them in synch makes things easier to track. Especially when there's a de-facto ABI change with every release ;-)
Then., the name '1.33' somehow suggests two levels of versions, while really there is only one (by the way: why do you carry the '1.' around ? Do you expect a 'release 2' at some point ? If so, in what way would such a release be different from an upgrade from 1.32 to 1.33, say ?)
Heh, very good quesion! -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Stefan Seefeld <seefeld@sympatico.ca> writes:
Then., the name '1.33' somehow suggests two levels of versions, while really there is only one (by the way: why do you carry the '1.' around ? Do you expect a 'release 2' at some point ? If so, in what way would such a release be different from an upgrade from 1.32 to 1.33, say ?)
Heh, very good quesion!
Yes it is. Boost really should have just released v33.1. Then, a version with FOREACH and whatnot could be 33.2. Any patch release to fix last minute problems with 33.1 would be 33.1.1. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: David Abrahams <dave@boost-consulting.com>
Stefan Seefeld <seefeld@sympatico.ca> writes:
Then., the name '1.33' somehow suggests two levels of versions, while really there is only one (by the way: why do you carry the '1.' around ? Do you expect a 'release 2' at some point ? If so, in what way would such a release be different from an upgrade from 1.32 to 1.33, say ?)
Heh, very good quesion!
Yes it is. Boost really should have just released v33.1. Then, a version with FOREACH and whatnot could be 33.2. Any patch release to fix last minute problems with 33.1 would be 33.1.1.
Well, I'm not sure I agree. The problem I see with '1.33' is that it suggests a difference between the number before the dot and after, or, put differently, distinct release cycles for major and minor releases (which typically come with specific semantics as to ABI / API compatibility). If you don't want to give any guarantee concerning compatibility between two subsequent releases, you should IMO use simple numbers (32, 33, ...), and leave the 'dot releases' to packagers and distributors (such as redhat, debian, etc.) to roll their own bug-fix releases, and let those care for compatibility issues to satisfy their customers. Regards, Stefan
Stefan Seefeld wrote:
Rob Stewart wrote:
From: David Abrahams <dave@boost-consulting.com>
Stefan Seefeld <seefeld@sympatico.ca> writes:
Then., the name '1.33' somehow suggests two levels of versions, while really there is only one (by the way: why do you carry the '1.' around ? Do you expect a 'release 2' at some point ? If so, in what way would such a release be different from an upgrade from 1.32 to 1.33, say ?)
Heh, very good quesion!
Yes it is. Boost really should have just released v33.1. Then, a version with FOREACH and whatnot could be 33.2. Any patch release to fix last minute problems with 33.1 would be 33.1.1.
Well, I'm not sure I agree. The problem I see with '1.33' is that it suggests a difference between the number before the dot and after, or, put differently, distinct release cycles for major and minor releases (which typically come with specific semantics as to ABI / API compatibility). If you don't want to give any guarantee concerning compatibility between two subsequent releases, you should IMO use simple numbers (32, 33, ...), and leave the 'dot releases' to packagers and distributors (such as redhat, debian, etc.) to roll their own bug-fix releases, and let those care for compatibility issues to satisfy their customers.
I think the convention on Redhat, and probably others, is to use -release. Just like I did with boost-1.33.0-9.srpm. That is, vendor updates don't use '.', they use '-'.
Neal Becker wrote:
I think the convention on Redhat, and probably others, is to use -release. Just like I did with boost-1.33.0-9.srpm. That is, vendor updates don't use '.', they use '-'.
Right. But how are the changes reflected in the DSO names ? Wasn't that the origin of this whole thread ? There needs to be a way for packagers to express 'minor release with no ABI changes', but if the full range of three position numers ('1.33.1') is already taken by boost.org itself, even without *any* semantics attached, that's hard to do without confusing users. Regards, Stefan
Stefan Seefeld wrote:
Neal Becker wrote:
I think the convention on Redhat, and probably others, is to use -release. Just like I did with boost-1.33.0-9.srpm. That is, vendor updates don't use '.', they use '-'.
Right. But how are the changes reflected in the DSO names ? Wasn't that the origin of this whole thread ? There needs to be a way for packagers to express 'minor release with no ABI changes', but if the full range of three position numers ('1.33.1') is already taken by boost.org itself, even without *any* semantics attached, that's hard to do without confusing users.
_If_ we could implement some process for verifying/tracking ABI compatibility, then I think it would be sensible to set soname to e.g., libboost_python.so.1.33. The first actual library conforming to that ABI is libboost_python.so.1.33.0. A compatible update is libboost_python.so.1.33.1, which uses the same soname to indicate compatibility.
Neal Becker wrote:
_If_ we could implement some process for verifying/tracking ABI compatibility, then I think it would be sensible to set soname to e.g., libboost_python.so.1.33. The first actual library conforming to that ABI is libboost_python.so.1.33.0. A compatible update is libboost_python.so.1.33.1, which uses the same soname to indicate compatibility.
Right, and until there is such a device consider all releases to be major (i.e. ABI inompatible) warranting a major number increase. Regards, Stefan
From: Stefan Seefeld <seefeld@sympatico.ca>
Rob Stewart wrote:
From: David Abrahams <dave@boost-consulting.com>
Stefan Seefeld <seefeld@sympatico.ca> writes:
Boost really should have just released v33.1. Then, a version with FOREACH and whatnot could be 33.2. Any patch release to fix last minute problems with 33.1 would be 33.1.1.
Well, I'm not sure I agree. The problem I see with '1.33' is that it suggests a difference between the number before the dot and after, or, put differently, distinct release cycles for major and minor releases (which typically come with specific semantics as to ABI / API compatibility).
Right.
If you don't want to give any guarantee concerning compatibility between two subsequent releases, you should IMO use simple numbers (32, 33, ...), and leave the 'dot releases' to packagers and distributors
I suggested using "simple numbers" only as major version numbers. Boost does release patches to release builds, hence the current discussion as to whether there would be a 1.33.1. I contend that version should be 33.1.1.
(such as redhat, debian, etc.) to roll their own bug-fix releases, and let those care for compatibility issues to satisfy their customers.
As Neal pointed out, any versioning they might choose to do would be outside the dashes. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
I suggested using "simple numbers" only as major version numbers. Boost does release patches to release builds, hence the current discussion as to whether there would be a 1.33.1. I contend that version should be 33.1.1.
Fine. But as long as it carries the same 'major version number' (33) it should be ABI-compatible with that release or else that number looses its meaning. Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
Then., the name '1.33' somehow suggests two levels of versions, while really there is only one (by the way: why do you carry the '1.' around ? Do you expect a 'release 2' at some point ? If so, in what way would such a release be different from an upgrade from 1.32 to 1.33, say ?)
David Abrahams wrote:
Heh, very good quesion!
Just one random observer's opinion! I have been wondering the same thing since around Boost 1.25 - what would prompt an update in the major version number? One possibility would be the accepance of library TR1 - which adopts many boost libraries into a standard namespace, one of Boost's founding goals. However, I figured what would really make a claim for v2 would be a more fundamental change in the language itself. I am trying to imagine Boost in a post-C++0x world (x to be termined, probably hexadecimal) We will have several new language features to take advantage of - this could have far reaching implications to many libraries. Hopefully new language features will take out whole layers of metaprogramming trickery and cleverness, allowing much more direct and clear implementations, maybe making some libraries redundant. Almost certainly several boost libraries will have been adopted into the standard library itself, making a duplicate copy in boost maybe little more than a fall-back for compiling pre-standard code. Meanwhile, not all compiler vendors will have made the jump to the new standard, so we are left in the cleft stick of supporting C++03, or going with the new standard. That seems like a good time to cut ties with old compilers (such as VC6 and Gcc 2.95) and focus on libraries appropriate for the new language. If (and it is a very big 'if') the community of Boost authors wanted to adopt the new standard without falling over backwards with (broken!) C++03 support, that would be a very good time to kick off a Boost v2 project - possibly retaining Boost 1 in a 'bug fix' / compatibility mode, much as Spirit 1.6 continues to be supported for old compilers while 1.8 is the actively developed branch in Boost. Of course I am not a contributing author, and so my opinion should be weighed accordingly ;?) But it seemed like a good time to bring up the question of Boost post C++0x. -- AlisdairM
On Mon, 15 Aug 2005 20:17:21 +0000 (UTC) "AlisdairM" <alisdair.meredith@uk.renaultf1.com> wrote:
Meanwhile, not all compiler vendors will have made the jump to the new standard, so we are left in the cleft stick of supporting C++03, or going with the new standard.
That seems like a good time to cut ties with old compilers (such as VC6 and Gcc 2.95) and focus on libraries appropriate for the new language.
I think dropping support for some compilers would constitute a major upgrade, regardless of any new features, functionality, etc.
Jody Hagins wrote:
On Mon, 15 Aug 2005 20:17:21 +0000 (UTC) "AlisdairM" <alisdair.meredith@uk.renaultf1.com> wrote:
Meanwhile, not all compiler vendors will have made the jump to the new standard, so we are left in the cleft stick of supporting C++03, or going with the new standard.
That seems like a good time to cut ties with old compilers (such as VC6 and Gcc 2.95) and focus on libraries appropriate for the new language.
I think dropping support for some compilers would constitute a major upgrade, regardless of any new features, functionality, etc.
Removing features should never constitute an upgrade. Jonathan
On Mon, 15 Aug 2005 23:21:29 -0600 "Jonathan Turkanis" <technews@kangaroologic.com> wrote:
I think dropping support for some compilers would constitute a major upgrade, regardless of any new features, functionality, etc.
Removing features should never constitute an upgrade.
Sure it does. We see examples of addition through subtraction in many areas of life and engineering. Removing the complexity that surrounds support for many old compilers is an incredible upgrade, IMO. Consider some of the major problems with ACE, and you will quickly see that many are due simply to the breadth of support for decreped compilers and operating systems. Dropping compilers that did not support namespaces and other rudimentary "features" was a great "upgrade." While the breadth of support has helped boost gain wide acceptance, it is also the single biggest fault of the library as well.
Jody Hagins <jody-boost-011304@atdesk.com> writes:
On Mon, 15 Aug 2005 23:21:29 -0600 "Jonathan Turkanis" <technews@kangaroologic.com> wrote:
I think dropping support for some compilers would constitute a major upgrade, regardless of any new features, functionality, etc.
Removing features should never constitute an upgrade.
Sure it does. We see examples of addition through subtraction in many areas of life and engineering.
Removing the complexity that surrounds support for many old compilers is an incredible upgrade, IMO.
IMO there is very little likelihood that officially dropping full support for a compiler is going to happen on a Boost-wide basis, and there's even less likelihood that it will be accompanied by a great simplification in source code for any individual library. Most likely it will be accompanied by the addition of features that couldn't be made to work with the compiler. The only time I guess a library will actually rip out code that supports a compiler is during a total or near-total rewrite.
Consider some of the major problems with ACE, and you will quickly see that many are due simply to the breadth of support for decreped compilers and operating systems.
?? My impression was that the major problems had to do with a lack of stratification and modularization.
Dropping compilers that did not support namespaces and other rudimentary "features" was a great "upgrade."
While the breadth of support has helped boost gain wide acceptance, it is also the single biggest fault of the library as well.
?? Breadth of support has many benefits and only a few costs, and most of those fall on the library maintainers. Library users (ahem, like you) might pay for a slight reduction in velocity, but that's all. -- Dave Abrahams Boost Consulting www.boost-consulting.com
I think it is a bit unfortunate that we don't have a system to determine whether boost updates break existing api's. The usual process is that, for example, suppose we have
libboost.so.1.33.0
Let's assign this soname libboost.so.1. Then a symlink is created
libboost.so.1 -> libboost.so.1.33.0.
Symlink is generated via ldconfig on linux, other dynamic loader machinery on other systems. You can't simply do this link randomly and expect it to work: it's generated from the way the shared object is constructed. (Not the way it's named, at least not on all systems.)
Now if a bugfix comes out that does not change the api, be can have
ABI, not API.
libboost.so.1.33.1, which also has soname libboost.so.1, and then symlink:
libboost.so.1 -> libboost.so.1.33.1
...the rest is largely correct for linux in particular. The boost build/configure machinery can be made to work with linux conventions. Thanks Rene! However, boost in the past has not made this kind of interim release. I realize, after catching up on this list, that they may or may not do something like 1.33.1 in the future. This kind of minor release would be welcome, however I wait for it to actually happen before substantially altering the current RPM strategy.
OK, so that's the background. AFAICT, we (boost) don't have any way to tell if a new release breaks existing api, and whether to up the version. I think that is unfortunate. I don't really know what to do about it, though.
This is unfortunate. There is a difference between API and ABI. Not all API changes are ABI incompatible. For the record, there exists some Red Hat testing infrastructure for the boost rpms. Between 1.32.0-6 and 1.33.0-1, there were substantial ABI differences. Because of this, the SONAME was bumped in accordance to existing linux conventions. For those interested, I will attach some of these results to this email as an attachment. It is my opinion, as a mere observer and packager, that boost cares not a wit about compatibility. And you know what? This is fine with me: these are supposed to be experimental libraries and should not be constrained, design wise, with the restraints of backwards compatibility with past (flawed) experiments. Thus, packagers for each system should determine how this stuff fits together, and deal with the fallout in a way that they deem sensible. best, benjamin
participants (11)
-
AlisdairM -
Benjamin Kosnik -
David Abrahams -
Jeremy Maitin-Shepard -
Jody Hagins -
Jonathan Turkanis -
Neal Becker -
Rene Rivera -
Rob Stewart -
Stefan Seefeld -
Vladimir Prus