Re: [CLN-list] CLN 1.2.1 -- silent ABI change?
Bruno Haible wrote:
Hi Richy,
Indeed: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473494>.
This can be solved by rebuilding the Ginac package, no?
Yes.
Oh, no! Oh, no, no nooooo!!! This entire library versioning scheme sucks so big time. I've read all the docs and it didn't help because I missed that change. It is theoretical mumbo-jumbo unless one has an actual ABI testsuite and uses it on a regular basis. This is especially true for C++ libraries.
Theoretical mumbo-jumbo? The docs say that a library maintainer has to determine four things: - Has the library source code has changed at all? I make diffs for the entire source code between the previous and the current release. - Have any interfaces have been added, removed, or changed? I make diffs for the include/ directory between the previous and the current release. - Have any interfaces have been added? Same. - Have any interfaces have been removed? Same.
Frankly, it hadn't occurred to me that anybody would diff the package against the previous release. (Maybe one could diff symbols using nm, or so.) Anyway, there are two more options for CLN-1.2.2: * Back out the patch. * Add a function that re-establishes binary compatibility but don't expose it in the public header file. Still pondering... -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Dear Richard, On Thu, Apr 03, 2008 at 08:13:32AM +0200, Richard B. Kreckel wrote:
Anyway, there are two more options for CLN-1.2.2:
* Back out the patch.
The patch ("Avoid gcc warnings about type-punning and "... break strict-aliasing rules") is really necessary.
* Add a function that re-establishes binary compatibility but don't expose it in the public header file.
I'm afraid this will make CLN unsafe to compile with -O2 again. Best regards, Alexei -- All science is either physics or stamp collecting.
Dear Alexei, Alexei Sheplyakov wrote:
* Add a function that re-establishes binary compatibility but don't expose it in the public header file.
I'm afraid this will make CLN unsafe to compile with -O2 again.
I don't think so. It would make the two functions unsafe. But these functions can be used only by programs compiled against CLN-1.2.0. Programs compiled using CLN-1.2.1 are safe anyway as the bad signature doesn't exist and programs compiled using CLN-1.2.2 are safe because the bad signature is not exposed and, hence, not used. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Dear Richard, On Thu, Apr 03, 2008 at 09:38:10AM +0200, Richard B. Kreckel wrote:
I don't think so. It would make the two functions unsafe. But these functions can be used only by programs compiled against CLN-1.2.0. Programs compiled using CLN-1.2.1 are safe anyway as the bad signature doesn't exist and programs compiled using CLN-1.2.2 are safe because the bad signature is not exposed and, hence, not used.
OK, this sounds reasonable. Best regards, Alexei -- All science is either physics or stamp collecting.
Alexei Sheplyakov wrote:
On Thu, Apr 03, 2008 at 09:38:10AM +0200, Richard B. Kreckel wrote:
I don't think so. It would make the two functions unsafe. But these functions can be used only by programs compiled against CLN-1.2.0. Programs compiled using CLN-1.2.1 are safe anyway as the bad signature doesn't exist and programs compiled using CLN-1.2.2 are safe because the bad signature is not exposed and, hence, not used.
OK, this sounds reasonable.
I've checked in such a patch and plan to release CLN-1.2.2 tomorrow. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Dear Richard, On Sat, Apr 05, 2008 at 01:02:39AM +0200, Richard B. Kreckel wrote:
I've checked in such a patch and plan to release CLN-1.2.2 tomorrow.
CL_CURRENT=5 -CL_REVISION=1 +CL_REVISION=2 CL_AGE=0 I think this version info is incorrect. It should be CL_CURRENT=6 # new functions were added CL_REVISION=0 CL_AGE=1 # but still it's binary compatible with CLN 1.2.0 Best regards, Alexei -- All science is either physics or stamp collecting.
Dear Alexei, Alexei Sheplyakov wrote:
CL_CURRENT=5 -CL_REVISION=1 +CL_REVISION=2 CL_AGE=0
I think this version info is incorrect. It should be
CL_CURRENT=6 # new functions were added CL_REVISION=0 CL_AGE=1 # but still it's binary compatible with CLN 1.2.0
Really?!? Let's read what the libtool documentation has to say about its versioning system. Hmm, yes, I see... Let's assume that in CLN-1.2.3 functions are removed. This would become: CL_CURRENT=7 CL_REVISION=0 CL_AGE=0 The net result is that soname-wise, libcln.so.7 directly follows libcln.so.5. Quite confusing. Is that really the intent? Or am I supposed to decrement CL_CURRENT again? So far, my practice has been to try to care that later libraries with soname libcln.so.x are compatible with earlier ones with same soname and to increment soname whenever compatibility breaks. From a software distribution point of view (wearing my Debian hat), this should be all that matters. If I had done this the way libtool suggests, we would already have libcln.so.21 or so. After all, this is C++, where library interfaces are usually less stable than in C. I'm releaseing it now the way it is. Don't hesitate to tell if you think that this way of doing versions is fundamentally wrong. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi Richard, * Richard B. Kreckel wrote on Sat, Apr 05, 2008 at 11:00:01PM CEST:
Really?!? Let's read what the libtool documentation has to say about its versioning system. Hmm, yes, I see...
The net result is that soname-wise, libcln.so.7 directly follows libcln.so.5. Quite confusing. Is that really the intent? Or am I supposed to decrement CL_CURRENT again?
FWIW, I haven't looked closer at your actual issue here, but: The libtool naming scheme cannot guarantee that on all systems, the numbering is consecutive. It only guarantees that it is increasing. This doesn't matter, though: there is not incurred cost for numbers that are omitted, except for shrinking the available space of leftover numbers. Not something you need to worry about yet. ;-)
If I had done this the way libtool suggests, we would already have libcln.so.21 or so. After all, this is C++, where library interfaces are usually less stable than in C.
There's nothing wrong about libcln.so.21, though. Cheers, Ralf
participants (3)
-
Alexei Sheplyakov
-
Ralf Wildenhues
-
Richard B. Kreckel