Date:	Tue, 17 Feb 1998 17:19:56 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc:	djgpp-workers AT delorie DOT com, DJ Delorie <dj AT delorie DOT com>
Subject:	Re: Some questions.
In-Reply-To:	<m0y4gAa-000S1oC@inti.gov.ar>
Message-ID:	<Pine.SUN.3.91.980217170802.6103C-100000@is>
MIME-Version:	1.0

On Tue, 17 Feb 1998, Salvador Eduardo Tropea (SET) wrote:

> Well I know it sounds crazy, but I want it in DJVerify to detect mixed 
> installations. That's a common problem (people saying: Why RHIDE pass only 128 
> bytes to gcc?).

I think that if you need to check for specific functionality, you should 
just check for it, period.  For example, in the case of long command 
lines, pass a long command to gcc and see what it got (by using -v and 
redirecting its stdout/stderr).  Otherwise you will wind up dealing with 
too many combinations of different versions.  One problem is that every 
version of Binutils comes with a different stub built into it, which 
might be none of those distributed with stock DJGPP versions.  Another 
problem is that people might recompile some of the tools using their own 
patched libc about which you don't have a clue, and the dates won't help 
you.

> Additionally stub-less COFF files can be detected by the library version.

Not if people use patched libraries.  The version signature is only 
changed by DJ when he builds the library.  I doubt if anybody else cares 
to bump the version with every patch.  And even if they do, you don't 
know anything about their private version numbering.  Since a patched 
libc is now available by courtesy of Tom Demmer, these cases might be 
more frequent than you think.

> And 
> very mixed things can be only created by people using alphas or similar stuff 
> that normally knows what happends without the need of any kind of verify 
> program.

But people who ``know what they are doing'' could send a binary to 
somebody who doesn't know.  For example, the stock version of dif271b.zip 
was linked against a version of libc from beta-testing period of v2.01.  
It turns out that this version didn't know about "/dev/null", so if you 
try something like "diff -c /dev/null foo" (a common way for making a 
patch file which creates a new file), you get an error message.  Such 
problems are bound to happen, and it would be nice if diagnostic tools 
such as DJVerify won't be confused by them.

For these reasons, I think that if you want to test for specific 
problems, just test them, don't rely on versions.

Anyway, this is only my $0.02, feel free to disregard.

- Raw text -