Date: Tue, 17 Feb 1998 17:19:56 +0200 (IST) From: Eli Zaretskii To: "Salvador Eduardo Tropea (SET)" cc: djgpp-workers AT delorie DOT com, DJ Delorie Subject: Re: Some questions. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.