mirror of
https://github.com/postgres/postgres.git
synced 2026-07-12 02:55:34 -04:00
4a1b05caa5
The concerns that led us to remove AIX support in commit0b16bb877have now been alleviated: 1. IBM has stepped forward to provide support, including buildfarm animal(s). 2. AIX 7.2 and later seem to be fine with large pg_attribute_aligned requirements. Since 7.1 is now EOL anyway, we can just cease to support it. 3. Tossing xlc support overboard seems okay as well. It's a bit sad to drop one of the few remaining non-gcc-alike compilers, but working around xlc's bugs and idiosyncrasies doesn't seem justified by the theoretical portability benefits. 4. Likewise, we can stop supporting 32-bit AIX builds. This is not so much about whether we could build such executables as that they're too much of a pain to manage in the field, due to limited address space available for dynamic library loading. 5. We hit on a way to manage catalog column alignment that doesn't require continuing developer effort (see commitecae09725). Hence, this commit reverts0b16bb877and some follow-on commits such ase6bb491bf, except for not putting back XLC support nor the changes related to catalog column alignment. Some other notable changes from the way things were in v16: Prefer unnamed POSIX semaphores on AIX, rather than the default choice of SysV semaphores. Include /opt/freeware/lib in -Wl,-blibpath, even when it is not mentioned anywhere in LDFLAGS. Remove platform-specific adjustment of MEMSET_LOOP_LIMIT; maybe that's still the right thing, but it really ought to be re-tested. Silence compiler warnings related to getpeereid(), wcstombs_l(), and PAM conversation procs. Accept "libpythonXXX.a" as an okay name for the Python shared library (but only on AIX!). Author: Aditya Kamath <Aditya.Kamath1@ibm.com> Author: Srirama Kucherlapati <sriram.rk@in.ibm.com> Co-authored-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CY5PR11MB63928CC05906F27FB10D74D0FD322@CY5PR11MB6392.namprd11.prod.outlook.com
32 lines
1.3 KiB
Text
32 lines
1.3 KiB
Text
src/port/README
|
|
|
|
libpgport
|
|
=========
|
|
|
|
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 strlcat.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. Windows, Linux, AIX, and macOS use an export
|
|
list to control the symbols exported by libpq.
|