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
