From 35a0601d0ae0b1ce64bb34ee8df65802f9b1265f Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Fri, 28 Apr 2006 02:52:57 +0000
Subject: [PATCH] Add info on pgport linking requirements.

---
 src/port/README | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100644 src/port/README

diff --git a/src/port/README b/src/port/README
new file mode 100644
index 00000000000..8314f9533fe
--- /dev/null
+++ b/src/port/README
@@ -0,0 +1,26 @@
+libpgport must have special behavior.  It supplies functions to both
+libraries and applications.  However, there are two complexities:
+
+1)  Libraries need to use object files that are compiled with exactly
+the same flags as the library.  libpgport might not use the same flags,
+so it is necessary to recompile the object files for individual
+libraries.  This is done by removing -lpgport from the link line:
+
+        # Need to recompile any libpgport object files
+        LIBS := $(filter-out -lpgport, $(LIBS))
+
+and adding infrastructure to recompile the object files:
+
+        OBJS= execute.o typename.o descriptor.o data.o error.o prepare.o memory.o \
+                connect.o misc.o path.o exec.o \
+                $(filter snprintf.o, $(LIBOBJS))
+
+The problem is that there is no testing of which object files need to be
+added, but missing functions usually show up when linking user
+applications.
+
+2) For applications, we use -lpgport before -lpq, so the static files
+from libpgport are linked first.  This avoids having applications
+dependent on symbols that are _used_ by libpq, but not intended to be
+exported by libpq.  libpq's libpgport usage changes over time, so such a
+dependency is a problem.  Win32 uses export list of symbols for libpq.
-- 
GitLab