statically linked gcc executables

John Carter john.carter@tait.co.nz
Tue Jan 29 13:14:00 GMT 2008


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.

Alas, Reality bites, we all suck, nobody on planet with a non-trivial
product has perfect test coverage of code and state, and we all have
bugs.

And even if you have really really good coverage, you seldom have the
time to rerun _every_ test after every change.

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.

Test what like you fly, fly what you test.

And that applies to shipping products to customers, it applies to
internal products like shipping cross compilers to colleagues.

As I said, Reality truly sucks.

Hint: C/C++ based reality sucks even more since, unless you test
heavily under Valgrind, most code has subtle uninitialized data bugs
that often don't fire under even the heaviest testing. One of the
reasons I like dynamic languages like Ruby.


John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand



More information about the Gcc-help mailing list