Date: Tue, 17 Feb 1998 18:07:07 +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: > 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.