Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

Kris Jurka <books(at)ejurka(dot)com> writes:
> consider what would happen if the shared library didn't exist at all and
> only a static version were available. Until this recent batch of pgcrypto
> changes everything built fine.

Well, the right answer to that really is that pgcrypto ought not try to
link to libz unless a shared libz is available (compare for instance the
situation with plperl and an unshared libperl). However, I'm not sure
that we could reasonably expect to make a configuration test that would
detect a situation like this --- that is, if we did look for shared
libz, we would find it, and the fact that a nonshared libz in a
different place would cause the actual link to fail seems like something
that configure would be unlikely to be able to realize.

I'm still of the opinion that your libz installation is broken; the fact
that some other products chance not to fail with it is not evidence that
it's OK. You could for instance have installed both libz.a and libz.so
from the same build in /usr/local/lib, and that would work fine,
independently of the existence of a version in /usr/lib.

Come to think of it, are you sure that the versions in /usr/lib and
/usr/local/lib are even ABI-compatible? If they are from different zlib
releases, I think you're risking trouble regardless. Really the right
way to deal with this sort of thing is that you put libz.a and libz.so
in /usr/local/lib and corresponding headers in /usr/local/include, and
then you don't need to sweat whether they are exactly compatible with
what appears in /usr/lib and /usr/include.

regards, tom lane