Kris Jurka <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend