2010/3/11 Tom Lane <t...@sss.pgh.pa.us>: > Now libpq doesn't often have critical security bugs filed against it, > but it certainly has bugs. Do you really want to have to remember to > rebuild every piece of dependent software when you update it?
I absolutely agree that linking statically is a terrible idea for distributions. Debian has a similar prohibition against linking statically against any other package. But it does ship static libraries because commercial binary-only packages often require them. They have to be packaged to work on multiple OS distributions including some which don't provide especially smooth dependency systems. You don't want to get calls from customers running your software against random library versions you've never tested. The two (separate) goals which are useful are 1) Provide a library others can link against to produce a binary which has no run-time dependency on your library. In this case the only library they might want to link against would be libpq. The encoding libraries etc aren't things they're going to link agains. And 2) build binaries which have no dependencies on system libraries so someone can ship them and expect them to run on any system regardless of the run-time environment. I agree that these are both over-used but they are sometimes the least bad option. On the other hand, the third goal "avoid using the shared library facilities" is pointless, I see no reason to avoid building and loading the encoding code or the contrib modules. They're using the same technology as shared libraries but they're not really shared libraries in the sense of being shipped separately from the binaries using them. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers