pgsql: Prevent accidental linking of system-supplied copies oflibpq.so - Mailing list pgsql-committers
From | Tom Lane |
---|---|
Subject | pgsql: Prevent accidental linking of system-supplied copies oflibpq.so |
Date | |
Msg-id | E1f3SVR-0006A4-IB@gemulon.postgresql.org Whole thread Raw |
List | pgsql-committers |
Prevent accidental linking of system-supplied copies of libpq.so etc. We were being careless in some places about the order of -L switches in link command lines, such that -L switches referring to external directories could come before those referring to directories within the build tree. This made it possible to accidentally link a system-supplied library, for example /usr/lib/libpq.so, in place of the one built in the build tree. Hilarity ensued, the more so the older the system-supplied library is. To fix, break LDFLAGS into two parts, a sub-variable LDFLAGS_INTERNAL and the main LDFLAGS variable, both of which are "recursively expanded" so that they can be incrementally adjusted by different makefiles. Establish a policy that -L switches for directories in the build tree must always be added to LDFLAGS_INTERNAL, while -L switches for external directories must always be added to LDFLAGS. This is sufficient to ensure a safe search order. For simplicity, we typically also put -l switches for the respective libraries into those same variables. (Traditional make usage would have us put -l switches into LIBS, but cleaning that up is a project for another day, as there's no clear need for it.) This turns out to also require separating SHLIB_LINK into two variables, SHLIB_LINK and SHLIB_LINK_INTERNAL, with a similar rule about which switches go into which variable. And likewise for PG_LIBS. Although this change might appear to affect external users of pgxs.mk, I think it doesn't; they shouldn't have any need to touch the _INTERNAL variables. In passing, tweak src/common/Makefile so that the value of CPPFLAGS recorded in pg_config lacks "-DFRONTEND" and the recorded value of LDFLAGS lacks "-L../../../src/common". Both of those things are mistakes, apparently introduced during prior code rearrangements, as old versions of pg_config don't print them. In general we don't want anything that's specific to the src/common subdirectory to appear in those outputs. This is certainly a bug fix, but in view of the lack of field complaints, I'm unsure whether it's worth the risk of back-patching. In any case it seems wise to see what the buildfarm makes of it first. Discussion: https://postgr.es/m/25214.1522604295@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/dddfc4cb2edcfa5497f5d50190a7fb046c51da16 Modified Files -------------- contrib/dblink/Makefile | 2 +- contrib/hstore_plperl/Makefile | 2 +- contrib/hstore_plpython/Makefile | 2 +- contrib/jsonb_plperl/Makefile | 2 +- contrib/jsonb_plpython/Makefile | 2 +- contrib/ltree_plpython/Makefile | 2 +- contrib/oid2name/Makefile | 2 +- contrib/postgres_fdw/Makefile | 2 +- contrib/spi/Makefile | 2 -- contrib/vacuumlo/Makefile | 2 +- src/Makefile.global.in | 25 +++++++++++++++-------- src/Makefile.shlib | 10 +++++++-- src/backend/replication/libpqwalreceiver/Makefile | 3 ++- src/bin/initdb/Makefile | 2 +- src/bin/pg_basebackup/Makefile | 2 +- src/bin/pg_ctl/Makefile | 2 +- src/bin/pg_dump/Makefile | 2 +- src/bin/pg_rewind/Makefile | 2 +- src/bin/pg_upgrade/Makefile | 2 +- src/bin/pgbench/Makefile | 2 +- src/bin/psql/Makefile | 2 +- src/bin/scripts/Makefile | 2 +- src/common/Makefile | 8 ++++---- src/interfaces/ecpg/compatlib/Makefile | 4 ++-- src/interfaces/ecpg/ecpglib/Makefile | 3 ++- src/interfaces/ecpg/pgtypeslib/Makefile | 2 +- src/interfaces/ecpg/test/Makefile.regress | 5 +++-- src/interfaces/ecpg/test/compat_informix/Makefile | 3 +-- src/interfaces/libpq/test/Makefile | 4 ++-- src/makefiles/pgxs.mk | 4 +++- src/test/examples/Makefile | 4 ++-- src/tools/findoidjoins/Makefile | 2 +- 32 files changed, 66 insertions(+), 49 deletions(-)
pgsql-committers by date: