RE: AIX support

Hi Tom and community members,

Thank you very much for the support and guidance so far. Please find attached v2 of the meson changes. (See: 0001-Add-AIX-support-for-Postgresql-using-meson-build-too.patch)

Based on your feedback for the s_lock.h changes, we have integrated the changes to our patch and tested the same in our environment (Power AIX and Power Linux).

Please git apply this patch and kindly build using meson in AIX. Build instructions and the patch summary are in the commit message.

>1. AIX 7.1 is now EOL, and people seem comfortable with not
>re-supporting it.

Yes, AIX will support only AIX 7.2 TL5 and higher oslevels in the near future.

>2. People also seem comfortable with only supporting gcc not xlr
>(and reasonably late-model gcc, to avoid some old bugs therein).
>We are probably also okay with only supporting 64-bit builds.

Yes, in open-source communities for AIX we only support GCC and ibm-clang compiler. (64-bit builds). For PostgreSQL we want to concentrate on GCC compiler.

One example is meson as mentioned in the document here.
https://mesonbuild.com/Release-notes-for-1-6-0.html#support-for-openxl-compiler-in-aix

>* int8 vs float8 alignment issue
>The configure changes in the present patch are hacky, and worse they
>do not solve the problem: we'd still need weird coding rules for any
>float8 column in the system catalogs.
>which is reasonably clean code-wise but would force a dump-and-reload
>rather than pg_upgrade to go from <= v16 to v19. Is that good enough?
>* s_lock.h changes: it's not okay to change anything affecting non-AIX
>I've done a little research on this topic, which I'll include in a
>separate message.

We have checked your changes and integrated the same in this version of the patch which worked. Thank you once again for the same. Please check the s_lock.h file in this patch.

>* -D_H_FLOAT hack
>This should no longer be necessary after Michael's commit d46aa32ea.

Yes, we have synced our branch today with Michael’s changes. Thank you Michael for the same.

>* do we really still need mkldexport.sh?
>I can understand people's distaste for this, but in the big scheme
>of things I don't find it to be a showstopper. It'd be nice if
>someone who's familiar with the relevant AIX tools would annotate
> it with some comments explaining what it's doing, though.

Yes Tom. We have added the comment in the "src/backend/meson.build” file. Please check the same.

AIX does not automatically make symbols from an executable available to shared modules at runtime. As a result, extension modules cannot resolve references to functions in the main postgres binary unless those symbols are explicitly exported. On AIX an executable is not a default provider of symbols; shared modules must link against an export list that specifies exactly which symbols they may import. The mkldexport.sh script uses nm command to extract symbols from the object files that form the postgres executable and generates this export list. When invoked with ".", the script emits "#! .", indicating that the export list refers to the main executable itself, which in turn allows extension libraries to resolve their undefined symbols against the postgres binary. The linker flags -Wl,-bE:<exportfile> mark symbols exported by the postgres binary, while -Wl,-bI:<exportfile> instruct the AIX linker/loader to import those symbols for a shared module that depends on them. So while making the Postgres binary the line

backend_link_args += '-Wl,-bE:@0@'.format(postgres_imp.full_path())

Creates a -Wl,bE:<path>/postgres.imp export file which will be used by the plugins to import.

One example being ./build/tmp_install/usr/local/pgsql/lib64/latin_and_mic.so which will have -Wl,bI:<path>/postgres.imp when it is getting created.

> So it's not clear why this patch is introducing things
> like dep_static_lib, and the lack of comments about that doesn't help.

On AIX, both static and shared libraries are archived, because multiple shared libraries with different ABIs or versions may need to coexist within the same archive for backward compatibility. Meson follows this AIX convention when using the Ninja backend, which means that static and shared libraries end up with identical archive names. Unlike Linux, where static archives use “.a” and shared libraries use “.so”, AIX archives both under “.a”, causing Meson to report name conflicts when a target tries to build both forms. To address this, the dep_static_lib variable was introduced so that each target can explicitly choose whether it wants to build the static version, the shared version, or both, with the default remaining flexible. For AIX, we are building only shared.

Comments are kept in meson.build file.

Link for the same: https://mesonbuild.com/Release-notes-for-1-6-0.html#support-for-openxl-compiler-in-aix

>So, with the possible exception of the int8/float8 alignment issue,
>it seems to me we're within striking distance of a committable patch.
>I wonder whether anyone still wants to argue that AIX support is
>unsustainable on these terms. My own opinion is that it's probably
>okay, and we can always rip it out again if IBM fails to follow
>through on support from their end.

Thank you for the encouraging words. We are glad to hear the patch is now considered close to committable. We also appreciate the perspective on the sustainability of AIX support under the updated terms. We are committed on our side to ensuring the platform remains supportable and maintainable going forward.

Thanks again for the guidance and support throughout this effort.

Let us know what you think of this version of the patch. Your feedback is greatly appreciated.

Best regards,

Aditya.