Re: AIX support

Srirama Kucherlapati <sriram(dot)rk(at)in(dot)ibm(dot)com> writes:
> We have set the below flags for building the source

> export OBJECT_MODE=64
> export FLAG64="-maix64"
> export CC__=/opt/freeware/bin//gcc-12
> export CXX__=/opt/freeware/bin//g++-12
> export CC64="${CC__}"
> export CFLAGS="${FLAG64} -O2 "
> export GLOBAL_CC_OPTIONS="-O2"
> export CC="${CC64} "
> export LDFLAGS="-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=$LDFLAGS:/opt/freeware/lib64/perl5/5.38/CORE/:
> export PYTHON=/opt/freeware/bin/python3.9
> export AR='/usr/bin/ar -X64’

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=64 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 := $(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 <envar>OBJECT_MODE</envar> to 64 and
pass <literal>CC="gcc -maix64"</literal>
to <command>configure</command>.

(It also said to set LDFLAGS="-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 -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -fvisibility=hidden -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: *** [<builtin>: test_cplusplusext.o] Error 1
| ^~~~~~~~~~~~~~
make[5]: *** [<builtin>: 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