2010-09-20 22:08:53 +02:00
|
|
|
src/port/README
|
2008-03-21 14:23:29 +01:00
|
|
|
|
|
|
|
libpgport
|
|
|
|
=========
|
|
|
|
|
2006-04-28 04:52:57 +02:00
|
|
|
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
|
2006-04-28 06:39:41 +02:00
|
|
|
dependency is a problem. Win32, Linux, and Darwin use an export list to
|
2006-04-28 04:59:11 +02:00
|
|
|
control the symbols exported by libpq.
|