Liste des Groupes | Revenir à c arch |
In article <vasruo$id3b$1@dont-email.me>, david.brown@hesbynett.no (DavidIt is indeed simpler when you produce binaries. (We make embedded systems - for many products, we have full control of the of software and the hardware, which makes it a lot easier to have a consistent test environment.)
Brown) wrote:
On 30/08/2024 17:42, John Dallman wrote:I always have at least a couple of machines at the previous buildPlain old compiler bugs, introduced while fixing other ones, are>
quite enough to make me assume that I'll find problems on each
change of compiler.
I always keep old versions of compilers around, and don't change
compilers (or libraries) in the middle of a project.
standard of any platform, often more machines and/or older build
standards.
Changing compilers or libraries is done at new major releases.
If you want to write software that is "correct because it passedThis is simpler when you produce closed-source binary software. We only
its tests", you can only expect it to be reliable when it is run
exactly as tested. That means it must be compiled as it was during
tests (same compiler, same options, same library), and arguably
even run only on the same hardware (if you only test on one
particular cpu, OS, etc., you can only be sure it works on that
cpu, OS, etc.).
ship builds we've tested. That means the /same binaries/ as we tested,
not rebuilt or modified. This requires a separate test harness, rather
than testing code compiled into the binaries.
We test on a wide variety of hardware for the most-used platforms, byThat is a good compromise.
putting it into the distributed testing pools and always knowing which
machine an individual test case ran on, because it's recorded in the test
results.
That's why a lot of pre-compiled commercial software givesWe specify what we specifically support, because we've tested that, plus
particular versions of particular OS's or Linux distributions in
their lists of requirements - even though the software would
probably work fine on a much wider range.
the much broader requirements that it should work on. For Linux those are
a GCC runtimes version (currently 8.x) or later and a glibc version
(currently 2.28) or later. We don't seem to have problems with
compatibility since we understood how the compatibility works with those
libraries, and started doing it that way.
If there's a problem on a specifically supported Linux, we'll fix itAgreed. For a lot of businesses, customer loyalty comes not from making working products (lots of people can do that), but how you handle things when something goes wrong.
unless that's impossible. If there's a problem on one where it should
work, we'll investigate it, and fix it if we can, which may cause a
distribution to be added to the specifically supported list. If we can't
fix a problem, we'll explain why not, and normally add the problem to the
documentation. We can't do miracles, but we do pretty well.
Yes, doing good support is expensive, but it pays off in customer loyalty,
which means money.
Les messages affichés proviennent d'usenet.