mirror of
https://github.com/postgres/postgres.git
synced 2026-02-25 02:44:39 -05:00
dddfc4cb2e
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
51 lines
1.3 KiB
Makefile
51 lines
1.3 KiB
Makefile
#-------------------------------------------------------------------------
|
|
#
|
|
# Makefile for src/bin/pg_ctl
|
|
#
|
|
# Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
|
# Portions Copyright (c) 1994, Regents of the University of California
|
|
#
|
|
# src/bin/pg_ctl/Makefile
|
|
#
|
|
#-------------------------------------------------------------------------
|
|
|
|
PGFILEDESC = "pg_ctl - starts/stops/restarts the PostgreSQL server"
|
|
PGAPPICON=win32
|
|
|
|
subdir = src/bin/pg_ctl
|
|
top_builddir = ../../..
|
|
include $(top_builddir)/src/Makefile.global
|
|
|
|
# On Windows, we need to link with libpq, just for use of pqexpbuffer;
|
|
# but let's not pull that in on platforms where we don't need it.
|
|
ifeq ($(PORTNAME), win32)
|
|
override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS)
|
|
LDFLAGS_INTERNAL += $(libpq_pgport)
|
|
SUBMAKE_LIBPQ := submake-libpq
|
|
endif
|
|
|
|
OBJS= pg_ctl.o $(WIN32RES)
|
|
|
|
all: pg_ctl
|
|
|
|
pg_ctl: $(OBJS) | submake-libpgport $(SUBMAKE_LIBPQ)
|
|
$(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X)
|
|
|
|
install: all installdirs
|
|
$(INSTALL_PROGRAM) pg_ctl$(X) '$(DESTDIR)$(bindir)/pg_ctl$(X)'
|
|
|
|
installdirs:
|
|
$(MKDIR_P) '$(DESTDIR)$(bindir)'
|
|
|
|
uninstall:
|
|
rm -f '$(DESTDIR)$(bindir)/pg_ctl$(X)'
|
|
|
|
clean distclean maintainer-clean:
|
|
rm -f pg_ctl$(X) $(OBJS)
|
|
rm -rf tmp_check
|
|
|
|
check:
|
|
$(prove_check)
|
|
|
|
installcheck:
|
|
$(prove_installcheck)
|