delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/02/17/11:07:26

Date: Tue, 17 Feb 1998 18:07:07 +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: <m0y4jMU-000S2hC@inti.gov.ar>
Message-ID: <Pine.SUN.3.91.980217175633.6103J-100000@is>
MIME-Version: 1.0

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

> Ok for gcc, and what about make or flex or ...

You need to check them all, of course.  It's the same as with what you 
wanted to do: every binary could be compiled and linked with different 
version of the library, right?  So if gcc is v2.01, Make or Flex still 
can be from v2.0, right?

> People recompiling such a things doesn't need an installation verifier, 
> or not?

You could of course tell that DJVerify only works for people who download 
binaries and don't rebuild them.  But I could imagine cases where those 
who do recompile need to figure out some mess...

> I really don't understand you at all. First you say that only DJ changes the 
> signature, then you talk about the patchs ...

I can patch the library without changing the version signature:

		gcc -c -O2 foo.c
		ar rvs /djgpp/lib/libc.a foo.o

Voila!  You have a patched libc with the same $Id string as the stock 
one.

> 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.

No, this is the case where nothing short of testing for a specific
functionality won't help.  The libc signature doesn't tell you what
bugs/features are in the programs, since different packages are built by
different people.  For example, all packages that I ported have binaries
linked with my patched libc, but the $Id signature in that libc is the
same as in the stock v2.01 libc.

> The only way for that is to know every problem.

You have to test specifically for every specific problem, yes.

> I just want to solve one: 2.00 v.s. 2.01.

Well, I thought the reason you wanted to do that was because of the long 
command lines that are passed differently, not because you care generally 
about v2.0 vs v2.01.  So I suggested to test for long lines support 
directly.

- Raw text -


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