postgresql.git/src/makefiles/Makefile.aix, branch master

Restore AIX support.

2026-02-23T18:34:22Z

The concerns that led us to remove AIX support in commit 0b16bb877 have 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 commit ecae09725). Hence, this commit reverts 0b16bb877 and some follow-on commits such as e6bb491bf, 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 Author: Srirama Kucherlapati Co-authored-by: Peter Eisentraut Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CY5PR11MB63928CC05906F27FB10D74D0FD322@CY5PR11MB6392.namprd11.prod.outlook.com

Remove AIX support

2024-02-28T11:17:23Z

There isn't a lot of user demand for AIX support, we have a bunch of hacks to work around AIX-specific compiler bugs and idiosyncrasies, and no one has stepped up to the plate to properly maintain it. Remove support for AIX to get rid of that maintenance overhead. It's still supported for stable versions. The acute issue that triggered this decision was that after commit 8af2565248, the AIX buildfarm members have been hitting this assertion: TRAP: failed Assert("(uintptr_t) buffer == TYPEALIGN(PG_IO_ALIGN_SIZE, buffer)"), File: "md.c", Line: 472, PID: 2949728 Apperently the "pg_attribute_aligned(a)" attribute doesn't work on AIX for values larger than PG_IO_ALIGN_SIZE, for a static const variable. That could be worked around, but we decided to just drop the AIX support instead. Discussion: https://www.postgresql.org/message-id/20240224172345.32@rfd.leadboat.com Reviewed-by: Andres Freund, Noah Misch, Thomas Munro

autoconf: Rely on ar supporting index creation

2022-10-07T18:53:39Z

This way we don't need RANLIB anymore, making it a bit simpler for the meson build to generate Makefile.global for PGXS compatibility. FreeBSD, NetBSD, OpenBSD, the only platforms where we didn't use AROPT=crs, all have supported the 's' option for a long time. On macOS we ran ranlib after installing a static library. This was added a long time ago, in 58ad65ec2def. I cannot reproduce an issue in more recent macOS versions. This is removed now. Based on discussion with Tom, I left the 'touch' at the end of static libraries generation, added in 826eff57c4c, in place. While it looks like current versions of Apple's ar/ranlib don't need it, it was needed not too long ago. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6clig6@awork3.anarazel.de

aix: No need to use mkldexport when we want to export all symbols

2022-09-10T02:11:49Z

When building a shared library with exports.txt there's no need to build an intermediary static library, we can just pass -Wl,-bE:... when generating the .so. When building a shared library without exports.txt, there's no need to call mkldexport.sh to export all symbols, because all symbols are exported anyway, and we don't need the export file on the import side (like we do for postgres.imp). This makes building .so's on aix a lot more similar to building on other platforms. In particular, we don't create and remove a .a of the same name but different contents anymore. Discussion: https://postgr.es/m/20220820174213.d574qde4ptwdzoqz@awork3.anarazel.de

aix: when building with gcc, tell gcc we're building a shared library

2022-09-01T18:49:36Z

Not passing -shared to gcc when building a shared library triggers linking to the wrong libgcc (libgcc.a instead of libgcc_s.a) and prevents emitting correct unwind information. It's somewhat surprising that this hasn't caused known problems so far. Doing so requires adding path to libgcc to libpath, or linking statically to libgcc - as the latter increases .so size substantially (for not entirely obvious reasons), shared linking seems preferrable. It likely is worth building executables with -shared-libgcc too, but I've not done that here. Discussion: https://postgr.es/m/20220820174213.d574qde4ptwdzoqz@awork3.anarazel.de

aix: Remove checks for very old OS versions

2022-08-07T16:36:01Z

Reviewed-By: Thomas Munro Discussion: https://postgr.es/m/20220807012914.ydz73yte6j3coulo@awork3.anarazel.de

Refactor DLSUFFIX handling

2022-03-25T07:56:02Z

Move DLSUFFIX from makefiles into header files for all platforms. Move the DLSUFFIX assignment from src/makefiles/ to src/templates/, have configure read it, and then substitute it into Makefile.global and pg_config.h. This avoids the need for all makefile rules that need it to locally set CPPFLAGS. It also resolves an inconsistent setup between the two Windows build systems. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/2f9861fb-8969-9005-7518-b8e60f2bead9@enterprisedb.com

Move port-specific parts of with_temp_install to port makefile.

2019-02-04T18:54:56Z

Rather than define ld_library_path_ver with a big nested $(if), just put the overriding values in the makefiles for the relevant ports. Also add a variable for port makefiles to append their own stuff to with_temp_install, and use it to set LD_LIBRARY_PATH_RPATH=1 on FreeBSD which is needed to make LD_LIBRARY_PATH override DT_RPATH if DT_RUNPATH is not set (which seems to depend in unpredictable ways on the choice of compiler, at least on my system). Backpatch for the benefit of anyone doing regression tests on FreeBSD. (For other platforms there should be no functional change.)

Ensure link commands list *.o files before LDFLAGS.

2019-01-02T18:57:54Z

It's important for link commands to list *.o input files before -l switches for libraries, as library code may not get pulled into the link unless referenced by an earlier command-line entry. This is certainly necessary for static libraries (.a style). Apparently on some platforms it is also necessary for shared libraries, as reported by Donald Dong. We often put -l switches for within-tree libraries into LDFLAGS, meaning that link commands that list *.o files after LDFLAGS are hazardous. Most of our link commands got this right, but a few did not. In particular, places that relied on gmake's default implicit link rule failed, because that puts LDFLAGS first. Fix that by overriding the built-in rule with our own. The implicit link rules in src/makefiles/Makefile.* for single-.o-file shared libraries mostly got this wrong too, so fix them. I also changed the link rules for the backend and a couple of other places for consistency, even though they are not (currently) at risk because they aren't adding any -l switches to LDFLAGS. Arguably, the real problem here is that we're abusing LDFLAGS by putting -l switches in it and we should stop doing that. But changing that would be quite invasive, so I'm not eager to do so. Perhaps this is a candidate for back-patching, but so far it seems that problems can only be exhibited in test code we don't normally build, and at least some of the problems are new in HEAD anyway. So I'll refrain for now. Donald Dong and Tom Lane Discussion: https://postgr.es/m/CAKABAquXn-BF-vBeRZxhzvPyfMqgGuc74p8BmQZyCFDpyROBJQ@mail.gmail.com

Fix PGXS support for building loadable modules on AIX.

2012-10-10T01:04:06Z

Building a shlib on AIX requires use of the mkldexport.sh script, but we failed to install that, preventing its use from non-source-tree contexts. Also, Makefile.aix had the wrong idea about where to find the installed copy of the postgres.imp symbol file used by AIX. Per report from John Pierce. Patch all the way back, since this has been broken since the beginning of PGXS.