Hi Tom and community members,
Thank you for all the patches. We have tested them and reviewed them.
While all tests pass from Meson build side, in the GNU build side we have an
issue with which I will explain below.
+# -blibpath must contain ALL directories where we should look for libraries
+libpath := $(shell echo $(subst -L,:,$(filter -L/%,$(LDFLAGS))) | sed -e's/
//g'):/usr/lib:/lib
+
+# 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
+
+rpath = -Wl,-blibpath:'$(rpathdir)$(libpath)’
These lines are no longer required, and we have removed it in v12 patch as
well. And this is the root cause of GNU tests failing.
The above lines cause the binary’s lib path to be as below:
***Import File Strings***
INDEX PATH BASE MEMBER
0
/usr/local/pgsql/lib:/usr/lib:/lib:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/13/
The GCC compiler on AIX will leave it to the IBM AIX linker to derive the
runtime loader path from the compile time library search paths.
When we run "gcc -print-search-dirs” it lists all the library paths as below.
install: /opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/13/
programs:
=/opt/freeware/libexec/gcc/powerpc-ibm-aix7.2.0.0/13/:/opt/freeware/libexec/gcc/powerpc-ibm-aix7.2.0.0/13/:/opt/freeware/libexec/gcc/powerpc-ibm-aix7.2.0.0/:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/13/:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/13/../../../../powerpc-ibm-aix7.2.0.0/bin/powerpc-ibm-aix7.2.0.0/13/:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/13/../../../../powerpc-ibm-aix7.2.0.0/bin/
libraries:
=/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/13/:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/13/../../../../powerpc-ibm-aix7.2.0.0/lib/powerpc-ibm-aix7.2.0.0/13/:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/13/../../../../powerpc-ibm-aix7.2.0.0/lib/:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/13/../../../powerpc-ibm-aix7.2.0.0/13/:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/13/../../../:/lib/powerpc-ibm-aix7.2.0.0/13/:/lib/:/usr/lib/powerpc-ibm-aix7.2.0.0/13/:/usr/lib/
These paths will be used in the blibpath of binaries.
In practice, the GCC driver also contributes its own runtime support directory
(where libgcc_s lives) to the link search, and the derived runtime path written
into the loader section ends up containing those locations without us manually
constructing -blibpath.
After removing the lib path and path from Makefile.aix we get the below library
search paths which is what we need to run test cases or run binaries,
***Import File Strings***
INDEX PATH BASE MEMBER
0
../../../src/port:../../../src/common:../../../src/fe_utils:../../../src/interfaces/libpq:/opt/freeware/lib:/opt/freeware/lib/gcc/powerpc-ibm-aix7.3.0.0/13/ppc64:/opt/freeware/lib/gcc/powerpc-ibm-aix7.3.0.0/13/../../../ppc64:/opt/freeware/lib/gcc/powerpc-ibm-aix7.3.0.0/13:/opt/freeware/lib/gcc/powerpc-ibm-aix7.3.0.0/13/../../..:/usr/lib:/lib
We tried it in the same node and were able to run the TAP tests as well
successfully without the mentioned above lines in Makefile.aix . Let me know if
you have any issues after removing the same. But those lines are no longer
needed given we will move to GCC and Clang(IBM openXL) in AIX for PostgreSQL.
These lines might be added while using xlc compiler back then to help binaries
have all the required path in it to find libraries.
The TAP test results after removing the lines are as follows:
t/049_wait_for_lsn.pl ................. ok
t/050_redo_segment_missing.pl ......... skipped: Injection points not supported
by this build
t/051_effective_wal_level.pl .......... ok
All tests successful.
Files=50, Tests=588, 597 wallclock secs ( 0.14 usr 0.06 sys + 15.01 cusr 22.69
csys = 37.90 CPU)
Result: PASS
gmake[2]: Leaving directory '/home/buildusr/postgres/src/test/recovery'
gmake[1]: Leaving directory '/home/buildusr/postgres/src/test’
>0001 is the same patch I posted before to solve the alignment
>issue by using _Pragma(pack).
This is okay.
>0002 is as close as I could get to a straight revert of the
>AIX-support-removal commits 0b16bb877 and e6bb491bf. I did
>not put back the bits concerned with xlc support, since we’re
>tossing that overboard. I also didn't put back the changes
>in maxalign computation (mooted by 0001), nor the regression
>test for catalog column alignment (ditto), nor the changes in
>s_lock.h (unnecessary after 0c9f46c42).
We want to remove the blibpath calculation from this patch for reasons
mentioned above.
>0003 through 0005 are changes needed on top of that, mostly
>0006 adds some definitions I found necessary to get a warning-free
>0007 arose from comparing the file sets installed by the autoconf
All these patches look good.
>* The meson build, but not the autoconf build, produces
>complaints about
>../src/common/pg_get_line.c: In function 'pg_get_line_append’:
>../src/common/pg_get_line.c:129:27: warning: '({anonymous})' may be used
>uninitialized [-Wmaybe-uninitialized]
> 129 | if (prompt_ctx && sigsetjmp(*((sigjmp_buf *)
> prompt_ctx->jmpbuf), 1) != 0)
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>I'm not so worried about the warning itself --- buildfarm member
>hake has also been showing this --- but why are the two builds
>different? Same compiler, pretty much the same switches, although
>I see Meson is injecting -pthread without being asked. Could that
>be responsible?
This is our understanding so far: when pthread support is enabled, sigsetjmp is
no longer a straightforward function call—it expands into a more complex macro.
The compiler’s warning refers to an “anonymous” value because the macro
expansion likely uses a GCC statement expression of the form ({ ... }). Within
that expansion, GCC creates a temporary variable to capture some intermediate
state or return value. Since the compiler cannot clearly determine that this
internal temporary is always initialized—especially under certain optimization
levels—it raises the -Wmaybe-uninitialized warning, even though the code itself
is correct.
>* plpython probably needs work, and I'm not sure about --with-llvm.
?I can't really test either of those for lack of installed packages.
>(Curiously, p9-aix1-postgres1 does seem to have a python installation
>in /opt/freeware, but it's incomplete: there's no Python.h anywhere.)
I have upgraded python3.12, dnf and installed the development package. You will
be able to detect python now.
>BTW, who should the commit message(s) list as authors on these
>patches, besides the two of you?
Kindly also add Peter Eisentraut <[email protected]>
>>> exec(): 0509-036 Cannot load program initdb because of the following errors:
>>> 0509-150 Dependent module libpq.a(libpq.so.5) could not be loaded.
>>> 0509-022 Cannot load module libpq.a(libpq.so.5).
>>> 0509-026 System error: A file or directory in the path name does not exist.
>(2) I don't really see why users should have to specify something that
>the build process can easily infer for itself.
>(3) the previous patch version worked without this. So, I don’t
>believe this requirement is necessary.
I am actually curious about this and was trying a custom installation path for
PostgreSQL in Linux.
# initdb -D $PWD/data
initdb: error while loading shared libraries: libpq.so.5: cannot open shared
object file: No such file or directory
Even in Linux on Power, we cannot find the library when we install PostgreSQL
in a non-standard installation path unless we export LD_LIBRARY_PATH like above.
So, in AIX we use LIBPATH instead. Did I miss in understanding here?
>I did mean to ask for installation of python and ccache if possible.
>plpython often presents portability issues so it'd be good to check that,
>and ccache just makes things faster,
We do not have ccache in AIX toolbox, but python3.12 is installed now. Please
check. Due to development package not installed we had that issue. Now in meson
we should be able to run 2500+ commands.
>Hmm. That might be an acceptable answer if there were any
>documentation instructing users to do that, but there isn’t.
Sure.
Document 0 says GCC compiler will archive shared libraries in AIX and document
1 says If
there are multiple targets with the same name, Meson will do nothing
and print an error message.
[0]:
https://mesonbuild.com/Release-notes-for-1-6-0.html#support-for-openxl-compiler-in-aix
[1]:
https://github.com/mesonbuild/meson/blob/548aebd0e3f105378ff2f71c1b1d141ef4c46c75/docs/markdown/Rewriter.md?plain=1#L75
>OSError: [Errno 28] No space left on device
Please see now. I have freed up my working directory.
>Hah, I've got at least part of the answer: that TOC warning appears
>if the backend is built with -O0, but not at higher -O levels.
>The apparent connection to autoconf vs. meson is because earlier
>versions of the patch were building at -O0, due to template/aix
Yes, Tom — you’re right. From what I know, TOC size on AIX is influenced not
just by the overall code size but by the number of unique references a module
needs. The TOC holds entries for external functions, global data pointers,
constants, and other symbols that require relocation. That means TOC pressure
increases with the number of distinct items that need TOC slots. At -O0, the
compiler performs no inlining or dead‑code elimination, so the unoptimized IR
often contains more relocations and unused globals, each of which can
contribute additional TOC entries. This is why TOC usage can actually be higher
in an unoptimized build, even if the resulting binary is smaller. Hope that
clarifies the behavior.
Kindly let me know what you think of the patch lines removal we requested. Hope
I have answered all the questions.
Thank you for all your help, efforts and support. Let us know if you have any
questions or need anything else in the node.
Thank and regards,
Aditya.
