Tom Lane wrote:
Should we try to make that a bit more consistent, and if so how?
The shenanigans in Makefile.shlib would get a lot simpler if we said
that shlib links always include LDFLAGS *plus* LDFLAGS_SL, but I would
think that that would carry substantial risk of breakage. Surely there
are cases where linker switches are appropriate for making executables
but not shlibs. Perhaps we should set up three variables instead of
two, viz
LDFLAGS = switches for linking both executables and shlibs
LDFLAGS_EX = extra switches for linking executables only
LDFLAGS_SL = extra switches for linking shlibs only
Then we could get rid of that untrustworthy hack for extracting -L
switches ...
While we're on the subject... this reminds me of another issue that's
come up a few times on the PostGIS mailing lists.
AFAICT pg_config doesn't have a method for generating LDFLAGS for libpq
client applications, only backend libraries with pg_config --libs.
Normally we just go for "-lpq" but that doesn't always seem to work on
platforms where you need to explicitly give all libpq dependencies
during link time, e.g.
http://postgis.refractions.net/pipermail/postgis-users/2010-April/026349.html.
Would LDFLAGS_EX in this case be what we need? If so, could it be
exposed via a pg_config --libpq option or similar?
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
