[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: backward compatability of tools

From: Dr. David Kirkby
Subject: Re: backward compatability of tools
Date: Fri, 21 Feb 2003 09:03:32 +0000

Roger Leigh wrote:

> Even in the case of GCC, why can't you build, say, 2.7.2, and then
> bootstrap 2.95.x and then 3.2.x in succession?  As long as there's an
> "upgrade path", there's no need for the current toolchain to be fully
> backward-compatible with every system out there.

Whether or not a bootstrap process is acceptable depends on why
someone wants that backward compatibility. I want backward
compatibility for two reasons:

1) To test software on a number of operating systems/hardware for
finding /platform/OS/word-size/shell/processor/...specific bugs. In
this case, bootstrapping software is *not* the best way to go. 

2) I'm developing a very CPU intensive distributed application for
solving problems of transmission lines:
This will use a network of computers. The plan is for this to
automatically determine the performance of the machines it has access
to, distributing the load in proportion to the performance of those
computers. Hence the fastest one does the most work, the slower ones

I wish to test the scheduling algorithm on a wide range of machines.
Hence I'm keen to see the fastest way to solve a problem, given a
range of hardware from a relatively new quad 450 MHz machine to an old
single 40 MHz processor machine. Whether or not its possible to build
the necessary MPI libraries on the oldest hardware I don't know, but
it probably is using disk space exported from a better machine. In
this case, hardware, but not software backward compatibility is

Hence there are several reasons people might need backward

If the developers insist on dropping backward compatibility, would it
not be better to at least do a test for old hardware/software (i.e.
determine a machine is running SunOs 4.1.4), print an informative
error message then exit, rather than produce the messages I received
about /tmp/foo1 /tmp/foo2 etc not being found ? If it was not too much
hassle, a suggestion to rebuild the application with autoconf version
x and automake version y would be even more useful. So the old
hardware/software is not supported fully, but at least it gives
someone a hint on how to get it working. 

I just compiled a 64-bit application and tried to run it on a Sun with
a 32-bit kernel.

bach /home/duke/davek % a.out
a.out: Exec format error. Wrong Architecture.
bach /home/duke/davek % 

at least I know now why a.out would not run. 

The configure script I produced with recent automake/autoconf did not
produce such a message, but instead just gave messages about files not
being found. 

Should well written software not respond with informative messages, no
matter how invalid the user input?

Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]