Link requirements creep - Mailing list pgsql-hackers

From Tom Lane
Subject Link requirements creep
Date
Msg-id 7416.1211060413@sss.pgh.pa.us
Whole thread Raw
Responses Re: Link requirements creep  ("Marko Kreen" <markokr@gmail.com>)
Re: Link requirements creep  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
I was displeased to discover just now that in a standard RPM build of
PG 8.3, psql and the other basic client programs pull in libxml2 and
libxslt; this creates a package dependency that should not be there
by any stretch of the imagination.

The reason of course is that configure puts -lxml2 -lxslt into LIBS
and psql's Makefile unquestioningly links with that list.  Back in
the days of static linking, this didn't hurt because unreferenced
libraries didn't get pulled into the executable.  But it seems that
at least with Linux' linker, you get a reference to every shared
library mentioned in the link command.

One possible answer is to put these two libraries into a special
make variable, comparable to the way that libossp-uuid is being
handled, and use that variable only where wanted.  However this
seems to be a band-aid solution; we'll inevitably have the same
kind of problem again in future.

Another approach we could take is to allow configure to dump
everything into LIBS, and institute a policy that no executable
includes LIBS verbatim.  Instead every link command must do something
like libpq already does:$(filter -lcrypt -ldes -lcom_err -lcrypto -lk5crypto -lkrb5  -lgssapi_krb5 -lgss -lssl -lsocket
-lnsl-lresolv -lintl, $(LIBS))
 
to explicitly list the libraries this executable might need.
This seems a lot more fail-safe, but it'd probably take awhile
to get the filter lists right; and this doesn't seem like a route
to a readily back-patchable solution.

Thoughts, better ideas?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: use of pager on Windows psql
Next
From: Bruce Momjian
Date:
Subject: Re: use of pager on Windows psql