Mail Archives: djgpp-workers/1998/02/17/11:07:26
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 -