Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: Eli Zaretskii , djgpp-workers AT delorie DOT com, DJ Delorie Date: Tue, 17 Feb 1998 12:39:30 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Some questions. References: In-reply-to: Precedence: bulk Eli Zaretskii wrote: > > 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. Ok for gcc, and what about make or flex or ... > 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. People recompiling such a things doesn't need an installation verifier, or not? > > 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. I really don't understand you at all. First you say that only DJ changes the signature, then you talk about the patchs ... I just want to catch incompatible versions, the only I know is 2.00 v.s. 2.01 nothing more. > > 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. What? You ARE showing a case where DJVerify will think that this is the right diff even when is a damaged one and the only way to know it is looking at the signatures of the libc. > For these reasons, I think that if you want to test for specific > problems, just test them, don't rely on versions. The only way for that is to know every problem. I just want to solve one: 2.00 v.s. 2.01. This problem can't be solved without looking the libc/stub signature, if you know a general way tell me. SET ------------------------------------ 0 -------------------------------- Visit my home page: http://set-soft.home.ml.org/ or http://www.geocities.com/SiliconValley/Vista/6552/ Salvador Eduardo Tropea (SET). (Electronics Engineer) Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574 Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA TE: +(541) 759 0013