delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/02/17/10:32:34

Message-Id: <m0y4jMU-000S2hC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Organization: INTI
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com,
DJ Delorie <dj AT delorie DOT com>
Date: Tue, 17 Feb 1998 12:39:30 +0000
MIME-Version: 1.0
Subject: Re: Some questions.
References: <m0y4gAa-000S1oC AT inti DOT gov DOT ar>
In-reply-to: <Pine.SUN.3.91.980217170802.6103C-100000@is>

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019