|
| 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. |