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.reix@atos.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
199of "/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
previousreturn 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
62of "/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?