Attached is an ebuild for Botan 1.5.5 (based on the current 1.4.12 ebuild). 1.5.5 in many cases 3 to 20 times faster at some operations due to better algorithms and the inclusion of some assembly, so it may be of interest to some users. The software itself has been tested on x86, amd64, sparc64, alpha, and ppc64. The ebuild has only been tested on x86.
Created attachment 78945 [details] ebuild for botan 1.5.5
Thanks for the bug report Jack. version 1.5.5 added. Also a bug report for you :-). Getting the library versions following the package version is wrong. Library versions should remain the same for releases that maintain backwards compatability. See something like http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/policies-shlib.html http://docs.hp.com/en/B2355-90655/ch05s08.html http://abicheck.sourceforge.net/
I just had a though that you maybe actually doing this too. Not sure. Please ignore if this is not the case and I'm sorry for jumping to conclusions.
Yes, Botan is doing it wrong - the problem is that getting C++ binary compatability is annoyingly tough (eg, adding a new variable or function to a class is often sufficient to break this). There are workarounds, but most of the ones I've seen have been pretty ugly, and for now I'm just punting on it by defining soversion=version. I figured it was better to potentially require multiple versions of the library than have some application fail in some drastic (or, worse, completely silent) way because I didn't realize/forgot something had changed and didn't bump the version. (Especially true on dev releases, since I'm usually doing various pieces of major code surgery then) Thanks for pointing it out though - I'll revisit this before I release 1.6 and see if it makes sense to use a fixed so version for those releases.
I should add, since I think it probably wasn't clear from what I wrote before, that that is why the soname is libbotan-x.y.z.so and not libbotan.so.x.y - basically to sidestep the dynamic linkers's version matching scheme entirely and force the build and runtime versions of the library to be the same.
