Re: [patch] build issues on Win32

Greg Stark <gsstark(at)mit(dot)edu> writes:
> 2010/3/10 David Fetter <david(at)fetter(dot)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