Dear Alexei, Alexei Sheplyakov wrote:
I've tried to install (and use) CLN 1.2.1. My programs linked with CLN 1.2.0 stopped working due to undefined symbols:
Oops. Indeed: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473494>.
$ ginsh ginsh: symbol lookup error: /usr/local/lib/libginac-1.3.so.2: undefined symbol: _ZN3cln23cl_double_to_DF_pointerERKNS_11dfloatjanusE
I think the SONAME should be changed to indicate incompatible changes.
diff --git a/configure.ac b/configure.ac index 051223e..9188ad9 100644 --- a/configure.ac +++ b/configure.ac @@ -91,8 +91,8 @@ dnl * if any functions/classes have been added, increment CL_AGE, dnl * if backwards compatibility has been broken, set CL_AGE to 0. dnl $(CL_CURRENT):$(CL_REVISION):$(CL_AGE) results in dnl libcln.so.$(CL_CURRENT)-$(CL_AGE) -CL_CURRENT=5 -CL_REVISION=1 +CL_CURRENT=6 +CL_REVISION=0 CL_AGE=0 dnl make substitutions AC_SUBST(CL_CURRENT)
<slab_my_forehead> 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. </slab_my_forehead> Anyway, I have two options now: a) Release CLN-1.2.2 with changed soname, although the ABI did not change wrt. CLN-1.2.1. b) Just ignore it and release CLN-1.2.2 as libcln.so.5. Seriously. I am under the impression that the amount of trouble incurred by just re-building GiNaC for all distros is dwarfed by the trouble induced by a soname bump. In Debian, it always takes many weeks till we've hinted depending packages into the testing distribution after a soname bump. I'll make up my. Until then, feel free to lobby me. Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>