Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vkpeS-002i82-3D for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Jan 2026 20:27:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vkpeS-00G22O-0E for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Jan 2026 20:27:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vkpeR-00G22G-25 for pgsql-hackers@lists.postgresql.org; Tue, 27 Jan 2026 20:27:04 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vkpeP-002csH-00 for pgsql-hackers@lists.postgresql.org; Tue, 27 Jan 2026 20:27:03 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 60RKQcEX573837; Tue, 27 Jan 2026 15:26:38 -0500 From: Tom Lane To: Srirama Kucherlapati cc: Peter Eisentraut , "pgsql-hackers@lists.postgresql.org" , Heikki Linnakangas , Tristan Partin , AIX PG user Subject: Re: AIX support In-reply-to: References: <61d9ecc8-da4e-487a-9774-838b044cda4d@eisentraut.org> <190704.1769449537@sss.pgh.pa.us> Comments: In-reply-to Srirama Kucherlapati message dated "Tue, 27 Jan 2026 16:21:12 +0000" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <570033.1769543679.0@sss.pgh.pa.us> Date: Tue, 27 Jan 2026 15:26:38 -0500 Message-ID: <573836.1769545598@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="UTF-8" Content-ID: <570033.1769543679.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Srirama Kucherlapati writes: > We have set the below flags for building the source > export OBJECT_MODE=3D64 > export FLAG64=3D"-maix64" > export CC__=3D/opt/freeware/bin//gcc-12 > export CXX__=3D/opt/freeware/bin//g++-12 > export CC64=3D"${CC__}" > export CFLAGS=3D"${FLAG64} -O2 " > export GLOBAL_CC_OPTIONS=3D"-O2" > export CC=3D"${CC64} " > export LDFLAGS=3D"-L/opt/freeware/lib64 -L/usr/lib64 -L/opt/freeware/lib= -L/usr/lib -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/= lib" > export LDFLAGS=3D$LDFLAGS:/opt/freeware/lib64/perl5/5.38/CORE/: > export PYTHON=3D/opt/freeware/bin/python3.9 > export AR=3D'/usr/bin/ar -X64=E2=80=99 Ouch. Our normal expectation is that you can build a working Postgres with nothing more complicated than ./configure && make && make install (well, maybe you want a nondefault --prefix and some feature options, but getting to a working executable shouldn't take much more than that). It's totally not okay to expect users to preset a bunch of environment variables, especially not if that requirement appears nowhere in the documentation. So one TODO item for your patch is to restore (and update) the AIX-specific portions of the documentation, particularly the build instructions. But I do not want to see anything as messy as the above in the build instructions. After re-reading what used to be in installation.sgml, I'm inclined to suggest that we just say that only 64-bit builds using gcc are supported on AIX. Surely the number of users still wanting 32-bit Postgres on AIX is indistinguishable from zero. Then we could remove the documentation about likely failure modes of a 32-bit build. (Also, perhaps we could bake the bits about OBJECT_MODE=3D64 and -maix64 into the autoconf/meson logic and not burden users with dealing with those?) After some digging, I realized that the cause of my build failure with not finding libgcc_s.a was that you'd removed this stanza that Makefile.aix used to have: # when building with gcc, need to make sure that libgcc can be found ifeq ($(GCC), yes) libpath :=3D $(libpath):$(dir $(shell gcc -print-libgcc-file-name)) endif I don't really understand how it works for you without that. I suppose that your explicit setting of LDFLAGS masked the problem, but doing that did not work for me, which I found was because our rpath logic overrides any externally-given -Wl,-blibpath setting. Were you perhaps building with --disable-rpath? In any case, manually putting every required directory into LDFLAGS is not sustainable. There's a reason our makefiles work so hard to build that list automatically. In any case, once I put back the missing Makefile.aix bit, I was able to get a working 64-bit build after doing what installation.sgml used to tell people: For a 64-bit build, set OBJECT_MODE to 64 and pass CC=3D"gcc -maix64" to configure. (It also said to set LDFLAGS=3D"-Wl,-bbigtoc", but that doesn't seem to be necessary anymore?) However, my build doesn't pass the core regression tests. There is one failure in float8.out, which on investigation is because lgamma(NaN) is failing (returning ERANGE) instead of silently returning NaN. That behavior is directly contradictory to what "man lgamma" says, so I guess they fixed it in recent AIX, but we probably need a workaround for AIXen that are still in the field. cfarm119 is running a just slightly back-rev AIX: $ oslevel -s 7300-01-02-2320 With the patch attached, I can get through "make installcheck". However, I'm unable to attempt "make check-world" because src/test/modules/test_cplusplusext doesn't compile: g++ -Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute -Wimpl= icit-fallthrough=3D3 -Wcast-function-type -Wshadow=3Dcompatible-local -Wfo= rmat-security -fno-strict-aliasing -fwrapv -fexcess-precision=3Dstandard -= g -O2 -fvisibility=3Dhidden -fvisibility-inlines-hidden -I. -I. -I../../.= ./../src/include -c -o test_cplusplusext.o test_cplusplusext.cpp In file included from ../../../../src/include/c.h:57, from ../../../../src/include/postgres.h:48, from test_cplusplusext.cpp:18: ../../../../src/include/pg_config.h:588:24: error: expected unqualified-id= before '__int128' 588 | #define PG_INT128_TYPE __int128 | ^~~~~~~~ ../../../../src/include/c.h:580:9: note: in expansion of macro 'PG_INT128_= TYPE' 580 | typedef PG_INT128_TYPE int128 | ^~~~~~~~~~~~~~ ../../../../src/include/pg_config.h:588:24: error: expected unqualified-id= before '__int128' 588 | #define PG_INT128_TYPE __int128 | ^~~~~~~~ ../../../../src/include/c.h:586:18: note: in expansion of macro 'PG_INT128= _TYPE' 586 | typedef unsigned PG_INT128_TYPE uint128 | ^~~~~~~~~~~~~~ make: *** [: test_cplusplusext.o] Error 1 | ^~~~~~~~~~~~~~ make[5]: *** [: test_cplusplusext.o] Error 1 I poked at trying to fix that, without success. This is a reasonably late-model g++: $ g++ --version g++ (GCC) 13.3.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE= . so I don't know why it doesn't like __int128. This is very new code, so there may be a non-AIX-specific issue for us to fix. (But I could not reproduce the issue on the nearest version I have at hand, g++ (GCC) 13.2.1 20240316 (Red Hat 13.2.1-7) from Fedora 38.) Another thing I noticed: ps status isn't working. (All the postmaster child processes look the same in "ps auxww".) I suppose you need to restore the AIX support in ps_status.c. FWIW, attached is a delta patch showing where I am now (on top of your v11 patch and the pgstat_slru.c hack I showed earlier). regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="mydelta.patch"; charset="us-ascii" Content-ID: <570033.1769543679.2@sss.pgh.pa.us> Content-Description: mydelta.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/float.c index b5a7c57e53a..641e7de21a0 100644 --- a/src/backend/utils/adt/float.c +++ b/src/backend/utils/adt/float.c @@ -2852,6 +2852,12 @@ dlgamma(PG_FUNCTION_ARGS) float8 arg1 =3D PG_GETARG_FLOAT8(0); float8 result; = + /* On some versions of AIX, lgamma(NaN) fails with ERANGE */ +#if defined(_AIX) + if (isnan(arg1)) + PG_RETURN_FLOAT8(arg1); +#endif + /* * Note: lgamma may not be thread-safe because it may write to a global * variable signgam, which may not be thread-local. However, this doesn'= t diff --git a/src/makefiles/Makefile.aix b/src/makefiles/Makefile.aix index e91b250fd19..d8d8a4d68b0 100644 --- a/src/makefiles/Makefile.aix +++ b/src/makefiles/Makefile.aix @@ -6,8 +6,11 @@ # -blibpath must contain ALL directories where we should look for librari= es libpath :=3D $(shell echo $(subst -L,:,$(filter -L/%,$(LDFLAGS))) | sed -= e's/ //g'):/usr/lib:/lib = -# AIX uses a stricter, more explicit approach. The runtime linker expects -# to tell it exactly where to look using -blibpath. +# when building with gcc, need to make sure that libgcc can be found +ifeq ($(GCC), yes) +libpath :=3D $(libpath):$(dir $(shell gcc -print-libgcc-file-name)) +endif + rpath =3D -Wl,-blibpath:'$(rpathdir)$(libpath)' = # gcc needs to know it's building a shared lib, otherwise it'll not emit ------- =_aaaaaaaaaa0--