Dear Chris, On Mon, 27 Jun 2005, Chris Dams wrote:
On Thu, 2005-06-09 at 22:49 +0200, Richard B. Kreckel wrote:
As you notice, this binary compatibilty issue makes your patch eligible for GiNaC 1.4.0 at best. If your patch solves a real problem, then we should reconsider it. But my impression was that it only solved a theoretical problem that no user of the library could possibly hit. Wrong?
Hello? Anybody home?
Not until yesterday, actually.
You have code in GiNaC that suggest protection against static initialization order problems that in fact does not do anything whatsoever. It should either be fixed or removed. Does anybody care about this?
Yes, I do. And, apparently, others do, too. :)
This is the second time that Richy leaves the discussion by not responding. I am getting more than a little irritated by this.
Oh, I disliked your first patch of January 8. However, removing the references is more than fine with me. I had actually intended to apply it unmodified to GiNaC-1.4, but I was lazy. I apologize for not having signalled to you my intent to apply your patch to HEAD.
I have no idea how Richy got the idea that my path only solves a "theoretical problem".
It is a theoretical problem in the sense that to our knowledge nobody has been bitten by it. This is quite different from the problem introduced in release 1.3.0 and finally solved by your patch in release 1.3.1. There, all statically linked programs in several Linux distros crashed upon startup. Anyways, your patch is fine and it was certainly correct to apply it. What we could argue about is whether it was necessary to apply it to the 1.3 branch. The problem is that the patch removes symbols from the library. You have to look at it from the point of view of a distro package maintainer or a system administrator. These folks do not care how meaningful a symbol is, or how bugfree a function is. All they care about is that the programs that depend on the library still work (a useful definition of "to work" being: they can be started). Now, any patch that removes a used symbol from the library without changing the soname breaks all depending programs (as ldd -r will tell you without actually invoking the apps). Users will then complain that the "compatible" library upgrade broke their code. For future reference, folks: We define a library branch (1.3.x, 1.4.x, etc.) by an interface version. Symbols shouldn't be removed by going from release x.y.n to x.y.n+1. We deliberately don't care about semantics, e.g. function return values may change by a patchlevel bump. Otherwise, it will hardly be possible to fix algorithmic bugs. If the urge to change the interface in an incompatible way becomes pressing, then, well, let's just change the minor version to y+1! It would be great if we could continue with this practice. It is an established strategy, altough it would be considered simplistic by some. Feel free to read the libtool texinfo documentation or [0] for a more complete (and certainly more confusing) treatise. Anyway: thanks, Chris, for your analysis and patch! Regards -richy. [0] <http://people.redhat.com/drepper/dsohowto.pdf> -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>