Re: statically linked gcc executables

[Ted Byers <r dot ted dot byers at rogers dot com>]

--- Angelo Leto <angleto@gmail.com> wrote:
> > --- John Carter <john.carter@tait.co.nz> wrote:
> > > On Thu, 24 Jan 2008, Ted Byers wrote:
> > >
> > > > You're half right.  If your program uses
> library
> > > X,
> > > > and  that library has a subtle bug in the
> function
> > > > you're using, then the result you get using a
> > > > different library will be different.  The fix
> is
> > > not
> > > > to ensure that you use the same library all
> the
> > > time,
> > > > but to ensure your test suite is sufficiently
> well
> > > > developed that you can detect such a bug, and
> use
> > > a
> > > > different function (even if you have to write
> it
> > > > yourself) that routinely gives you provably
> > > correct
> > > > answers.
> > >
> >
> > > So given how much reality sucks, one of
> eminently
> > > practical things you
> > > can do is reduce the variance between what you
> have
> > > tested and what
> > > you ship.
> > >
> > Right.  So what is the problem with not upgrading
> all
> > your development machines to a new release of the
> tool
> > chain you're using until you have proven the new
> > version of the toolchain won't break your code? 
> Or
> 
> the reason may be the following:
> you may want the old branches on your repository to
> work with the old
> libraries (note that changing a library could also
> mean changing a
> function's interfaces);
> The versions of your code which have already been
> released should not
> be further modified and even when you need to
> introduce small changes
> (e.g. change an error message) it is not always a
> good idea to use the
> new library, so you may need
> (at least for a given interval of time) to be able
> to use the old
> library on some branch. Furthermore the new library
> may produce
> different results not only because of some
> unexpected error, but
> simply because the library changes; sometime is
> useful to keep both
> the library in order to prepare the transition.
> 
I find this line of reasoning wholly inadequate.

It is one thing to maintain old branches of your code
base.  It is quite another to insist they continue to
work with tools rendered obsolete.  Yes, I know that
changing a library can involve changes to functions'
interfaces, but that is just another part of the cost
of maintaining your tools.

The bottom line is that if two versions of the same
program produce different results, one of them is
wrong (or in the case of tools based on environmental
models, one is more wrong than the other, since there
is no such thing as a "model" that is correct, only
models that are adequate and reliable).  For many
calculations, there is only one correct answer.  If
one version produces the correct answer and the other
produces something different, then the other is wrong
a needs to be fixed.  In other kinds of calculations,
it is already known that the result produced can only
be an estimate of the correct answer, and in most
cases (such as numeric integration) there are ways to
estimate the amount of error in the result.  In such a
case, when a genius in numeric methods produces a
better algorithm for doing, say, numeric integration,
then the new library may well produce a more accurate
result than the old, but also good, code (you have to
love people who can improve already decent code, rare
as they are: I would not hesitate to pay a premium for
their work).  In such a case, one still has evidence
that allows one to deduce the reason for any
difference, and once that determination has been made,
in my view professional ethics (focussed on how one
treats clients) requires that the improved code be
used in any and all variants of my own product (so
even old branches that I may be maintaining for
whatever reason will be improved with the use of the
new code).

If it is the case that the new version of the library
is buggy, then don't use it until it has been fixed. 
If, instead, the new version of the library brings a
bug in your existing codebase to light, then the old
baseline code is wrong and needs to be fixed.  If you
have a user who is stuck using the old branch, for
whatever reason, it is not a service to him to allow
the bug to remain unfixed.  To my mind, that means
that all branches we choose to maintain must build
correctly with whatever tools we are using in
production at the time.  It is, to me, a waste of
resources to attempt to maintain a suite of versions
of my development tools along with the suite of
branches of my own code base.  I will maintain as many
branches of my own codebase as needed (and that number
is typically very small, since most of these are only
for development purposes and end ultimately being
folding back into the trunk), but I will not maintain
countless variants of the tool chain I use (unless, of
course, a client is willing to pay a very high premium
to do so, contrary to any advice I may give him).  At
any one time, then, I have only one version of a
toolchain in use, and at most one more in an
assessment phase before being deployed (and this only
at the most opportune time based on detailed
information about what changes are needed in the suite
of branches that are being actively maintained).  Even
if I started a project using gcc 3.4.4, having
upgraded to gcc 4.2.1, I am not going to maintain all
versions of all branches of gcc since gcc 3.4.4, or
even most of them.  I am not even going to maintain
4.2.0, and any new release, from any branches I choose
to maintain, will be guaranteed to build properly with
4.2.1, but the user is on his own if for whatever
reason he wants to stick with gcc 4.2.0 or earlier. 
Similarly, when I decide to upgrade the version of gcc
I am using, I won't be supporting earlier versions of
it.  If I am releasing source code, I will state in
the release notes what toolchain was used for it. 
There will be nothing, though, that compells my users
to upgrade either their tools or their copies of my
code.  It is up to them to make the same kinds of
assessments I have made.  If they come to a different
conclusion, so be it.  If one of them wants to
maintain an old branch of code I have released, using
older tools, they are welcome to do so, but I will not
waste time on a toolchain I have set aside as obsolete
in favour of a new version of those tools.  I have,
for example, both MS Visual Studio V6 and MS Visual
Studio 2005  (commercial reasons require use of such
tools in some circumstances).  I am not going to waste
time making my code build using MS VS v6 when I have
MS VS 2005.  Doing so would certainly result in wasted
time and inferior code.  Once I make the decision to
upgrade my tools, I don't waste further time on the
old ones.

Cheers

Ted