Peter Eisentraut <peter_e@gmx.net> writes:
> My question is, shouldn't libpq be linked against *all* the libraries that
> are detected at configure time?
Um, no, I'd prefer to err on the side of conservatism here. I'd be
willing to do it that way if configure were conservative about what
libraries it adds to LIBS --- but in fact configure never met a library
it didn't like.
For example: I have no idea what configure thinks it's accomplishing by
looking for libPW and including -lPW into LIBS on *any* platform where
that doesn't instantly crash and burn. Perhaps somewhere there is a
platform where that's really necessary, but I dunno where or what for.
On HPUX, there is a libPW with some hoary old compatibility functions
that I'd just as soon not have linked in. If compiled -pg, the backend
actually fails to start unless I remove -lPW from the link. So, I'd
object pretty darn strongly to any linking tactic that carries any risk
of causing libPW to be linked into customer applications just because
they asked for libpq. Who knows what it'd break in a customer app that
we have no way of testing beforehand? Who even knows what the darn
thing *does* on any given platform?
There are doubtless comparable risks on other platforms with other
libraries. As long as configure's philosophy is "if libFOO exists
then I must want to link with it" then I don't want to link the
whole LIBS list into interface libraries.
> I guess what I'm saying is, there seems to be a double standard of
> -lcrypt, -lc, -lkrb, and -ldes versus all other libraries.
Yup, there is. -lc should be safe enough though ;-). As for the
others, we should be looking for ways to get them out of libpq's
dependencies, not looking for ways to add more wildcards to the stew.
regards, tom lane