This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: statically linked gcc executables
- From: John Carter <john dot carter at tait dot co dot nz>
- To: gcc-help at gcc dot gnu dot org
- Date: Tue, 29 Jan 2008 14:30:54 +1300 (NZDT)
- Subject: Re: statically linked gcc executables
- References: <225827.59935.qm@web88314.mail.re4.yahoo.com>
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