Hi Andres and Robert, Thank you for your guidance so far.
>I'd fix that aspect by doing the same thing in the autoconf build as we do in >meson, i.e. keep the file in the include dir. We already do that e.g. for >guc_tables.inc.c, see this src/backend/utils/Makefile stanza: ># These generated headers must be symlinked into src/include/. ># We use header-stamp to record that we've done this because the symlinks ># themselves may appear older than fmgr-stamp. >$(top_builddir)/src/include/utils/header-stamp: fmgr-stamp errcodes.h >>probes.h guc_tables.inc.c > cd '$(dir $@)' && for file in fmgroids.h fmgrprotos.h errcodes.h > probes.h >guc_tables.inc.c; do \ > rm -f $$file && $(LN_S) "../../../$(subdir)/$$file" . ; \ > done > touch $@ Thank you for this. We tried this. (Please see patch: fix-GNU-exp.patch) and we were able to compile on both GNU and meson. We also used the patch sent by Robert. (See: dont-include-include-utils.patch) # ls -l ./src/include/utils/wait_event_funcs_data.c lrwxrwxrwx 1 root system 59 Jan 29 06:49 ./src/include/utils/wait_event_funcs_data.c -> ../../../src/backend/utils/activity/wait_event_funcs_data.c This creates the soft link like probes.h # ls -l probes.h lrwxrwxrwx 1 root system 35 Jan 29 06:45 ./src/include/utils/probes.h -> ../../../src/backend/utils/probes.h >The issue here is legitimate, in the >sense that including src/include/utils in the include path for some >file doesn't seem legit to me. But fixing that problem by defining, >just on AIX, the same symbol that the system header defines seems like >clearly the wrong fix. What if we needed to include the actual float.h >somewhere? What if the problem also occurred on some other platform? >Please put a bit more thought into the right ways to (1) describe the >things you find to us and (2) fix them. You're right: adding src/include/utils to the include path was not legitimate and defining _H_FLOAT on AIX was only masking the underlying ordering issue rather than solving it correctly. After re‑evaluating the problem, I agree that the real fix is to go with the way we all along are discussing suggested in the last couple of threads. Hope this works for all of us. Let us know if we missed something or did it wrong. Will send a git format patch for meson build tool after this thread for review which will include all this information and what Tom suggested for the alignment such that one can git apply the patch and build using meson in AIX. Once again thank you for all your inputs. Have a nice day ahead. Thanks and regards, Aditya. From: Andres Freund <[email protected]> Date: Wednesday, 28 January 2026 at 11:03 PM To: Robert Haas <[email protected]>, Michael Paquier <[email protected]> Cc: Aditya Kamath <[email protected]>, Srirama Kucherlapati <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [EXTERNAL] Re: AIX support Hi, On 2026-01-28 10:41:52 -0500, Robert Haas wrote: > On Wed, Jan 28, 2026 at 10:20 AM Aditya Kamath <[email protected]> wrote: > > But here is the catch. It won’t pick the AIX system float.h. It will pick > > the Postgres "src/include/utilsfloat.h”. > > PostgreSQL's header should always be included as "utils/float.h" and > the system header should always be included as "float.h" (or, well, > <float.h>, presumably). So this confusion should not exist unless the > include paths are messed up. It doesn't seem correct to me that the > include path includes src/include/utils rather than just src/include, > but I see the same thing here: I agree that this is wrong. CCing Michael and Bertrand, they added this in fa88928470b5 and 1e68e43d3f0f. > which happens because of: > > wait_event = static_library('wait_event_names', > waitevent_sources, > dependencies: [backend_code], > include_directories: include_directories('../../../include/utils'), > kwargs: internal_lib_args, > ) > > which happens because wait_event_funcs.c contains: > > #include "wait_event_funcs_data.c" > > and for some reason, that file gets placed in src/include/utils. The reason for that is that the same invocation also generates wait_event_types.h, which is included by other headers. > The attached patch, which also adjusts wait_events.c, fixes it for me. Unfortunately I suspect that'll cause issues with make builds, because there the files are generated in a different place (src/backend/activity) and then only wait_event_types.h is copied to src/include. So including the files as utils/ won't work. I'd fix that aspect by doing the same thing in the autoconf build as we do in meson, i.e. keep the file in the include dir. We already do that e.g. for guc_tables.inc.c, see this src/backend/utils/Makefile stanza: # These generated headers must be symlinked into src/include/. # We use header-stamp to record that we've done this because the symlinks # themselves may appear older than fmgr-stamp. $(top_builddir)/src/include/utils/header-stamp: fmgr-stamp errcodes.h probes.h guc_tables.inc.c cd '$(dir $@)' && for file in fmgroids.h fmgrprotos.h errcodes.h probes.h guc_tables.inc.c; do \ rm -f $$file && $(LN_S) "../../../$(subdir)/$$file" . ; \ done touch $@ Alternatively: I'm not a fan of including .c files that are not actually working C. You could just make wait_event_funcs_data.c be a complete C file, defining waitEventData, that is then built as a standalone file. Greetings, Andres Freund
fix-GNU-exp.patch
Description: fix-GNU-exp.patch
dont-include-include-utils.patch
Description: dont-include-include-utils.patch
