statically linked gcc executables

Ted Byers
Thu Jan 31 15:32:00 GMT 2008

--- Angelo Leto <> wrote:
> On Jan 29, 2008 5:56 PM, Ted Byers
> >
> > 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.
> I don't wanna spend a lot of time to keep updated
> the old
> (unmanteined) branches, but I will keep them
> working, for historical
> reasons and because
> in the future I could have the need to compare some
> output data ....
> Then is not a problem if they use obsolete tools.
So we agree to disagree.  You have resources to use on
old branches, I don't.  Rather, I regard that as a
waste of resources better spent on QA.  Once a branch
is abandonned, I forget it.  I won't waste time either
maintaining it (i.e. keeping it working) or upgrading

But note, the important thing in older code is what it
does with the data, and that can be handled in a well
designed back end fully distinct from the user
interface.  If you're using fortran or C++, and you
ensure this code is as compliant with the extant
standard of the day, it won't stop compiling on
compliant compilers any time soon (apart from having
to deal with bugs due to unnoticed reliance on
undefined behaviour or on compiler's extensions, and
fixes to address deprecated features).  So if your
code for doing nonlinear systems theory related math,
which you mentioned a while ago, is written in C++
that is compliant with the standard, you ought to
still be able to compile it with a compliant compiler
50 years from now, with only a little fiddling with a
small selection of the sorts of bugs I mention above. 
This I know from occasionally having resorted to using
very old fortran code (because the algorithm used has
seen little significant improvement over the decades
and the code in question has become a standard in its
own right, having been published and the method seen
as the standard default method to use in a given
> >
> > 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).
> indeed, may be one of them is less accurate, but is
> not wrong, this
> depends from your requirements which may change. If
> a new library
> (an algorithm of the new algorithm) promise to
> produce more accurate
> results, this isn't a sufficient reason to use it,
> this accuracy must
> go together with the  "reliability" of the code
> (correct result for
> the whole representative set of input data), and
> sometime (not ever)
> the reliability of a code is not easy to be proved.
> In this case I
> would keep the
> old library until the tests procedures say that the
> code using new
> library is reliable.
> In critical environment the testing procedures are
> quite expensive,
> and you may need to keep different version of the
> same library (or
> tool) at least for the transitory period.
Yes, I know, from experience, testing is expensive. 
What you say here, though, is not all that different
that what I said about not deploying new tools until
they have been thoroughly tested.  The developers
continue using the tried and tested tools already
deployed, but they don't worry about the new tools
until senior staff have finished their evaluation.

> > For many
> > calculations, there is only one correct answer. 
> If for graphical interfaces for example, a change on
> the library may not
> produce a wrong or correct answer,
> but only a different result. In this case I will
> keep the library
> which fits better my needs, and I can decide to
> switch to this
> new library only on specific branches at a first
> time. When some
> functional changes are made to the library the
> problem is not if the
> result is
> wrong or correct, it's just different. In this case
> I would keep
> different versions of libraries for different
> branches because
> different behaviours
> may be desidered by different users.
So here, you have changed your concerns from the
quality of the output results to a question of taste. 
These things really don't matter.  I do not care if
the windows I create look like the Windows that
existed on MS Windows v 3.1 or those on Windows XP. 
That just doesn't matter.  If there are clients
willing to pay a significant premium, I may well
provide support for customizing the GUI to suite the
tastes of the user, but I won't put that there by

First, with a GUI, the conceptual model is trivially
simple, and it isn't all that hard to do with one GUI
library what you can do with another.  In the case, of
MS Windows, we have an extreme example where at least
the early versions of a new GUI library is written
using the previous standard library.  But look at
wxWindows, and descendants.  That is an impressive
example of how you can do using any GUI library what
you can do with any other.  Sometimes a given task is
easier, and at others harder, but it is always doable.

If you have clients willing to pay you to maintain
different GUI libraries, great.  But I would not waste
my time on it without good reason.

> ok for the improved code, but as I said, the
> differences can be on
> functional behaviour,
> in order to keep unchanged specific functionality,
> may be needed to
> use an older version of a library on a branch,
> and a new version where functionality is to be
> provided different.
> This is a reason which could make troublesome the
> installation
> of library directly on the system.
Perhaps, but it seems to me you're making too much
work for yourself.  It seems to me to be generally
easier to adapt the old code to make use of the new
library, even if that means adding a thunk layer to
map old calls to a new interface in the library or to
add perceived deficiencies in the new library.

> I will not mantain all the version of gcc used since
> the first branch.
> I can keep the different versions of toolchains on a
> sandbox,
> this way the system tools can be upgraded without
> problems and
> independently, without the worry of potential
> incoming problems.
> I will use the new toolchains on all the mantained
> versions but only
> after an in depth testing. Meanwhile the validated
> version of
> toolchains (or whatever) will be used.
So the principle difference between this, and what
I've been arguing, is the number of versions of the
tool chain to maintain.  You would opt to use several
in production, plus one or more in evaluation, while I
would insist on only one in production and no more
than one in evaluation.  

I can see problems if your machine is shared and you
don't have control over upgrade cycles, but that is a
different problem (and one I'd find intolerable).  If
I am working within an organization that has to
provide me with a shared machine, and my development
tools, I'd insist that they ensure that whatever else
they do with the system, they don't mess with my
development tools.  The function of the system
administrator who is responsible for administering the
machine I use include ensuring continual availability
of a development environment conducive to permitting
me to be as productive as possible.  System upgrades
can not be done just whenever the sysop gets a whim to
do so.



More information about the Gcc-help mailing list