Greg Stark <gsst...@mit.edu> writes: > 2010/3/10 David Fetter <da...@fetter.org>: >>>> --disable-shared, as previously mentioned. >> >> +1 for de-supporting this option.
> I would be sad about this. It seems likely there are platforms where > it's important. Any such platform would already be contending with plpgsql not working, encoding conversion not working, etc etc. It's barely conceivable that a client-only installation would be useful. But given that nobody has actually proposed supporting such a platform in the past ten years, I don't think one's likely to come out of the woodwork now. AFAICT the only case where anyone tries to do this is they have a personal preference to avoid shared libraries, for generally-pretty-darn-dubious reasons. Red Hat has developed a pretty strict policy against even shipping static libraries, because it's such a PITA to deal with updates. Let me give you a fresh-in-mind example: there is an open security bug against libpng (which I package for Red Hat in my copious spare time). I was distressed to find that fixing the bug left firefox still failing against a test web page. Investigation disclosed that the reason for this is that firefox is using a private static copy of libpng. That was a stupid decision on their part, as it means they're going to have to be involved in fixing this issue, not to mention past and future issues. 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? The OP's case apparently involves multiple independent libraries that he wants to link statically, which makes the problem multiple times worse. So my position is that static linking has enough negatives that you need a lot more than a hypothetical use-case to justify it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers