File tree Expand file tree Collapse file tree 1 file changed +26
-0
lines changed Expand file tree Collapse file tree 1 file changed +26
-0
lines changed Original file line number Diff line number Diff line change 1+ libpgport must have special behavior. It supplies functions to both
2+ libraries and applications. However, there are two complexities:
3+
4+ 1) Libraries need to use object files that are compiled with exactly
5+ the same flags as the library. libpgport might not use the same flags,
6+ so it is necessary to recompile the object files for individual
7+ libraries. This is done by removing -lpgport from the link line:
8+
9+ # Need to recompile any libpgport object files
10+ LIBS := $(filter-out -lpgport, $(LIBS))
11+
12+ and adding infrastructure to recompile the object files:
13+
14+ OBJS= execute.o typename.o descriptor.o data.o error.o prepare.o memory.o \
15+ connect.o misc.o path.o exec.o \
16+ $(filter snprintf.o, $(LIBOBJS))
17+
18+ The problem is that there is no testing of which object files need to be
19+ added, but missing functions usually show up when linking user
20+ applications.
21+
22+ 2) For applications, we use -lpgport before -lpq, so the static files
23+ from libpgport are linked first. This avoids having applications
24+ dependent on symbols that are _used_ by libpq, but not intended to be
25+ exported by libpq. libpq's libpgport usage changes over time, so such a
26+ dependency is a problem. Win32 uses export list of symbols for libpq.
You can’t perform that action at this time.
0 commit comments