Greg Stark <gsstark@mit.edu> writes:
> 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.
True. That still makes the current --disable-shared configure option
useless, but it doesn't go as far as suggesting that we ought to
implement --disable-static, which would be the logical conclusion from
my position.
I don't actually want to do --disable-static, but my feeling about it
is "if it breaks you get to keep both pieces". I'm not interested in
providing workarounds to let a static libpq be used in combination
with any-random-other-static-library. That's up to the user of the
thing to deal with.
BTW, I'm not sure I buy the argument that commercial software requires
static linking. Red Hat would be as interested in that market as
anybody, and as I said, they don't think it's necessary to ship static
libraries (with a *very* short list of exceptions).
regards, tom lane