When the libpq shared library is linked on my system it looks like this:

ld -Bdynamic -shared -soname libpq.so.2.1 -o libpq.so.2.1 fe-auth.o
fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o pqexpbuffer.o
dllist.o pqsignal.o   -lcrypt -lc

Now if I build a Kerberos IV enabled version it looks like

ld -Bdynamic -shared -soname libpq.so.2.1 -o libpq.so.2.1 fe-auth.o
fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o pqexpbuffer.o
dllist.o pqsignal.o   -lcrypt -lkrb -ldes -lc

Note that the relevant Kerberos libraries are specified so the user
doesn't have to remember linking his libpq programs against Kerberos.

My question is, shouldn't libpq be linked against *all* the libraries that
are detected at configure time? Imagine that libpq uses something from,
say, -lbsd. We'd never know because psql links against -lbsd so everything
is resolved but the end user may not know that and fail to link his
programs against -lbsd. I guess what I'm saying is, there seems to be a
double standard of -lcrypt, -lc, -lkrb, and -ldes versus all other
libraries.

Any library guru care to enlighten me?

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Thu, 15 Jun 2000 18:14:39 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Shared library interdependencies
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

Fri, 16 Jun 2000 03:15:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Shared library interdependencies 