Thread: Re: [GENERAL] PostgreSQL 8.3.8 on AIX5.3 : compilation failed
I CC: this to the hackers list as it seems to be an old problem that was never fixed. See at the bottom. Alexandra Roy wrote: > This is a summary of what I have noticed concerning > PostgreSQL 8.3.8 compilation on AIX 5.3 TL9. > > 1. To do a successful 64-bit build, specify and execute: > > > # export OBJECT_MODE="64" > # export CFLAGS="-maix64" > # export LDFLAGS="-maix64 -Wl,-bbigtoc" > # ./configure > # gmake > # gmake install I forgot to answer your question concerning the benefits of a 64-bit build: You will be able to use more memory. > 2. To do a successful 32-bit build, you must specify: > > > # export OBJECT_MODE="32" > > and use the "-disable-largefile" option with configure : > > > # ./configure -disable-largefile > > > If I use the "-disable-largefile" option, "configure" > indicates at the end: > > > configure: WARNING: option ignored: --enable-largefile > > > And then, the compilation is successful: > > > All of PostgreSQL successfully made. Ready to install. > > > Without the "-disable-largefile" option, the compilation is > still failing with this error: > > > In file included from psqlscan.c:2385: > /usr/include/unistd.h:171: error: conflicting types > for 'lseek64' > /usr/include/unistd.h:169: error: previous > declaration of 'lseek64' > was here > In file included from /usr/include/unistd.h:744, > from psqlscan.c:2385: > /usr/include/sys/lockf.h:64: error: conflicting > types for 'lockf64' > /usr/include/sys/lockf.h:62: error: previous declaration of > 'lockf64' was here > > > Does someone have an idea about this ? > Why the "-disable-largefile" option is necessary to do a > PostgreSQL 8.3.8 32-build ? > Why the "OBJECT_MODE" exported to 32 is not sufficient ? I dug around a little, and the problem is in psqlscan.c which is generated from psqlscan.l by flex. I found descriptions of the problem in the archives: http://archives.postgresql.org/pgsql-hackers/2002-09/msg01142.php http://archives.postgresql.org/pgsql-hackers/2002-09/msg01545.php The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined in this case, which makes #include <unistd.h> fail. A possible workaround, suggested by Peter Eisentraut at the time, would be to add this line at the beginning of bin/psql/psqlscan.c: #include "postgres.h" This fixes the problem for me. Does anyone have an idea how to best fix this problem in the source tree? I'm willing to implement and test. Yours, Laurenz Albe
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
>> Why the "OBJECT_MODE" exported to 32 is not sufficient ?
> I dug around a little, and the problem is in psqlscan.c which is generated
> from psqlscan.l by flex.
> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
> in this case, which makes #include <unistd.h> fail.
Yeah. We solved this and other problems years ago by decreeing that
we would never try to compile flex output files on their own; they'd
always be #include'd into some other source file so that pg_config.h
would get read first. psqlscan.l seems to have escaped that dictum
somehow, but I guess we'd better make it fall into line.
In most of the other cases the #include is done in an associated .y
file, but there is none in psql. Anyone have a thought which of
psql's .c files would be the most appropriate host?
regards, tom lane
Tom Lane wrote: > In most of the other cases the #include is done in an associated .y > file, but there is none in psql. Anyone have a thought which of > psql's .c files would be the most appropriate host? mainloop.c? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> In most of the other cases the #include is done in an associated .y
>> file, but there is none in psql. Anyone have a thought which of
>> psql's .c files would be the most appropriate host?
> mainloop.c?
Yeah, that's about the same conclusion I had come to --- that's
the principal caller so it's the closest analog to what we do
elsewhere.
Will fix.
regards, tom lane
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
> in this case, which makes #include <unistd.h> fail.
> Does anyone have an idea how to best fix this problem in the
> source tree? I'm willing to implement and test.
I've committed changes for this in CVS, please verify it fixes your
problem.
regards, tom lane
Tom Lane wrote: >> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined >> in this case, which makes #include <unistd.h> fail. >> Does anyone have an idea how to best fix this problem in the >> source tree? I'm willing to implement and test. > > I've committed changes for this in CVS, please verify it fixes your > problem. Problem fixed. Thanks for the quick work! Yours, Laurenz Albe