Peter Eisentraut <[email protected]> writes:
> Ok, that patch set looks pretty reasonable now.
> Can you confirm that this is the complete patch set required for AIX
> support?
> What version of AIX are you testing with?
> What compilers are you testing with?
I tried to build HEAD with 0001-Support-for-AIX.pg19.v11.patch
on the GCC compile farm (cfarm119.cfarm.net, which is running
AIX 7.3); I used gcc 13.3.0. I observed the following problems:
* The patch's changes to configure do not match those to configure.ac.
I used configure as-patched, so I don't know if it'd work after
re-running autoconf.
* In my tree, mkldexport.sh was created without execute permissions,
causing a build failure. I see that the patch says
new file mode 100755
so this is arguably the fault of the rather hoary version of
patch(1) that cfarm119 has. I mention it mainly to remind the
eventual committer to make sure mkldexport.sh is committed with
the correct permissions.
* I got this:
In file included from ../../../../src/include/postgres.h:48,
from pgstat_slru.c:18:
pgstat_slru.c:60:11: warning: no previous prototype for
'pgstat_count_slru_truncate64' [-Wmissing-prototypes]
60 | CppConcat(pgstat_count_slru_,stat)(int slru_idx) \
| ^~~~~~~~~~~~~~~~~~
../../../../src/include/c.h:429:41: note: in definition of macro 'CppConcat'
429 | #define CppConcat(x, y) x##y
| ^
pgstat_slru.c:84:1: note: in expansion of macro 'PGSTAT_COUNT_SLRU'
84 | PGSTAT_COUNT_SLRU(truncate)
| ^~~~~~~~~~~~~~~~~
and then
ld: 0711-317 ERROR: Undefined symbol: .pgstat_count_slru_truncate
On investigation, this is happening because <unistd.h> has
#define truncate truncate64
which causes "PGSTAT_COUNT_SLRU(truncate)" to expand as
"pgstat_count_slru_truncate64", which is not the name declared in
pgstat.h. An even more unfortunate result is that the "truncate"
field in PgStat_SLRUStats might actually be named "truncate64",
depending on whether <unistd.h> was read before pgstat.h.
I got around that by partially reverting eccba079c2ea:
diff --git a/src/backend/utils/activity/pgstat_slru.c
b/src/backend/utils/activity/pgstat_slru.c
index 2190f388eae..4d8ad3f20fc 100644
--- a/src/backend/utils/activity/pgstat_slru.c
+++ b/src/backend/utils/activity/pgstat_slru.c
@@ -81,7 +81,11 @@ PGSTAT_COUNT_SLRU(blocks_written)
PGSTAT_COUNT_SLRU(flush)
/* pgstat_count_slru_truncate */
-PGSTAT_COUNT_SLRU(truncate)
+void
+pgstat_count_slru_truncate(int slru_idx)
+{
+ get_slru_entry(slru_idx)->truncate += 1;
+}
I didn't have to make any other changes, so it seems that we are
currently consistent about always reading <unistd.h> first, but this
seems terribly fragile. We probably need some more-invasive answer,
like changing both the function and field name to "trunc" or something
like that.
* I also got some warnings:
auth.c: In function 'auth_peer':
auth.c:1877:13: warning: implicit declaration of function 'getpeereid'
[-Wimplicit-function-declaration]
1877 | if (getpeereid(port->sock, &uid, &gid) != 0)
pg_locale_libc.c: In function 'wchar2char':
pg_locale_libc.c:1243:26: warning: implicit declaration of function
'wcstombs_l'; did you mean 'wcstombs'? [-Wimplicit-function-declaration]
1243 | result = wcstombs_l(to, from, tolen, loc);
fe-connect.c: In function 'PQconnectPoll':
fe-connect.c:3598:45: warning: implicit declaration of function 'getpeereid';
did you mean 'getpwuid'? [-Wimplicit-function-declaration]
3598 | if (getpeereid(conn->sock,
&uid, &gid) != 0)
These did not break the build (so the functions do exist...) but
they need to be fixed.
After all that I was able to get through "make" and "make install",
but testing failed immediately:
bash-5.3$ initdb
exec(): 0509-036 Cannot load program initdb because of the following errors:
0509-022 Cannot load module
/home/tgl/testversion/lib/libpq.a(libpq.so.5).
0509-150 Dependent module libgcc_s.a(shr.o) could not be loaded.
0509-022 Cannot load module libgcc_s.a(shr.o).
0509-026 System error: A file or directory in the path name does not
exist.
So there's something wrong with the make rules for using libpq.so.
I do not know anything about AIX, so I can't debug this.
I was unable to test the meson patches, because meson isn't installed
on this machine.
I haven't actually read the patch, so don't take this as an
endorsement of the changes otherwise.
regards, tom lane
