[GiNaC-list] Re: GiNaC 1.3.1

[Richard B. Kreckel]

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/>