Re: PostgreSQL 11 beta1 on AIX 7.2 : 2 failures in 32bit mode

On Thu, May 31, 2018 at 10:28:12AM -0400, Tom Lane wrote:
> "REIX, Tony" <tony(dot)reix(at)atos(dot)net> writes:
> > It looks like configure does figure out that LARGE_FILES is required, only in 32bit.
> > No need in 64bit.
>
> Check ...
>
> > However, in 32bit, though there is:
> > #define _LARGE_FILES 1
> > in file :
> > src/include/pg_config.h
> > I had to add it at the beg of file by means of a patch to several files:
>
> This is surely not what's intended. It seems like plpython is messing
> things up somehow, probably through an #include-ordering error, but
> I don't see the exact problem offhand.
>
> I wondered why the existing 32-bit AIX buildfarm machines aren't showing
> problems, but looking closer at them, they are manually forcing
> _LARGE_FILES, which probably is masking things:
>
> 'config_env' => {
> 'CC' => 'wrap-gcc -D_THREAD_SAFE=1 -D_LARGE_FILES=1 -maix32',
>
> Noah, why'd you do that, and would you be willing to remove it? IMO
> Postgres should work without that.

I did that to work around a problem like the one articulated upthread.
Specifically, a 64-bit build w/ plpython failed:

xlc_r -qnoansialias -g -O2 -qmaxmem=16384 -qsrcmsg -qlonglong -I. -I. -I/home/nm/sw/python3-64/include/python3.4m -I../../../src/include -c -o plpy_elog.o plpy_elog.c
"/usr/include/unistd.h", line 201.17: 1506-343 (S) Redeclaration of lseek64 differs from previous declaration on line 199 of "/usr/include/unistd.h".
"/usr/include/unistd.h", line 201.17: 1506-050 (I) Return type "long long" in redeclaration is not compatible with the previous return type "long".
"/usr/include/unistd.h", line 201.17: 1506-377 (I) The type "long long" of parameter 2 differs from the previous type "long".
"/usr/include/sys/lockf.h", line 64.20: 1506-343 (S) Redeclaration of lockf64 differs from previous declaration on line 62 of "/usr/include/sys/lockf.h".
"/usr/include/sys/lockf.h", line 64.20: 1506-377 (I) The type "long long" of parameter 3 differs from the previous type "long".
... <more like that> ...

Today's "configure" test concludes that we don't need _LARGE_FILES, because
off_t is 64-bit ("long", specifically) in this configuration. The trouble
arises when Python.h does cause _LARGE_FILES to be defined. Some system
headers don't tolerate a mix of _LARGE_FILES values in one compilation. At
the time I added the workaround, I scratched down these candidates for a
proper fix:

1. Add "configure" test to determine whether Python defines _LARGE_FILES.
When it does, define it ourselves at the top of each Python-associated
source file.

2. Define _LARGE_FILES unconditionally on AIX. That is, adopt the workaround
as permanent.

3. Define _LARGE_FILES unconditionally. This should be harmless, but I
wouldn't tend to back-patch it.

4. Include system headers that react to _LARGE_FILES before including
Python.h. This is fragile; the list of affected headers may change.

I lean toward (2), because it will defend against other libraries choosing to
define _LARGE_FILES like Python does. It would cause problems if some library
does an explicit "#undef _LARGE_FILES", but that's a less-likely choice.
Other preferences?