On Thu, May 31, 2018 at 10:28:12AM -0400, Tom Lane wrote:
> "REIX, Tony" <[email protected]> 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?
