Обсуждение: port v7.0 to SGI-IRIX-6.5.7/64
I managed to compile (and sort of run) postgres 7.0 to SGI running IRIX 6.5.7. I compiled to 64bit libraries. The problems I had were both due errors in the configure script as well as postgres configuration files. configure problems: ------------------- 1- the program that configure uses to test for namespace std is faulty. I had to manually add #define HAVE_NAMESPACE_STD 1 to the top of interfaces/libpq++/pgconnection.h 2- configure badly guesses the type of the 3rd argument to accept(). it decided it should be size_t (unsigned int on IRIX) while accept on IRIX takes an int. postgres compiles, but accept never retrieves the IP address of the connecting client (in StreamConnection() function in the file backend/libpq/pqcomm.c). as a result no authentication can happen and the postmaster refuses connections regardless of what is in pg_hba.conf. the error message is usually something like "no pg_hba.conf entry for host localhost user postgres database template1" here local host is just a default string and apparently will never match anything in pg_hba.conf. to fix this i changed line 521 of include/config.h from: #define SOCKET_SIZE_TYPE size_t to: #define SOCKET_SIZE_TYPE int postgres problems ------------------ 3- src/pl/tcl/Makefile has a bug. line 69 is CFLAGS= $(TCL_CFLAGS_OPTIMIZE) that clobbers all CFLAGS included previously. as a result the include directories, important to find tcl.h etc. will not be added to the options and the compilation stops here complaining that it can't locate tcl.h etc. I just changed it to CFLAGS+= $(TCL_CFLAGS_OPTIMIZE) 4- I had to change line 8 of interfaces/odbc/isqlext.h from # include <isql.h> to # include "isql.h" to force the inclusion of the local isql.h now my questions: While compiling, i noticed a lot of warnings about pointers getting truncated etc. it seems that postgres assumes pointer sizes to be 32 bits. so I suppose compiling for a 64bit platform can be risky. Anyone have experience compiling postgres on a 64bit platform. a lot of the regression tests also failed. some of these failures don't seem to be trivial (some are trivial). I will paste below the overall report of the regression testing. But what I would really love is for someone to look at the my regression.diffs and kind of enlighten me to the problems I should expect with this installation or (better still) what to look at to fix the problems. I have not used postgres before and am actually fairly green with databases in general so any help is most appreciated. if interested I could email you the diffs for the above changes. Best Regards Murad Nayal configure command ----------------- ./configure --prefix=/local --with-includes=/local/include --with-libraries=/local/lib --with-tcl --with-tclconfig=/local/lib --with-tkconfig=/local/lib --with-perl --with-odbc --with-CC="cc -O2 -Xcpluscomm" --with-CXX="CC -O2" --with-x regression results ------------------ gmake runtest cc -O2 -Xcpluscomm -I../../include -I../../backend -I/local/include -U_NO_XOPEN4 -woff 1164,1171,1185,1195,1552 -Wl,-woff,15 -Wl,-woff,84 -I../../interfaces/libpq -I../../include -c regress.c -o regress.o ld -G -Bdynamic -shared -o regress.so regress.o MULTIBYTE=;export MULTIBYTE; \ /bin/sh ./regress.sh mips-sgi-irix6.5 2>&1 | tee regress.out =============== Notes... ================= postmaster must already be running for the regression tests to succeed. The time zone is set to PST8PDT for these tests by the client frontend. Please report any apparent problems to ports@postgresql.org See regress/README for more information. =============== dropping old regression database... ================= DROP DATABASE =============== creating new regression database... ================= CREATE DATABASE =============== installing languages... ================= installing PL/pgSQL .. ok =============== running regression queries... ================= boolean .. ok char .. ok name .. ok varchar .. ok text .. ok int2 .. failed int4 .. failed int8 .. failed oid .. ok float4 .. ok float8 .. ok numeric .. ok strings .. failed numerology .. failed point .. ok lseg .. ok box .. ok path .. ok polygon .. ok circle .. ok interval .. ok timestamp .. ok reltime .. ok tinterval .. failed inet .. ok comments .. ok oidjoins .. failed type_sanity .. failed opr_sanity .. failed abstime .. failed geometry .. failed horology .. failed create_function_1 .. ./regress.sh[116]: sql/create_function_1.sql: cannot open: No such file or directory diff: expected/create_function_1.out: No such file or directory diff: results/create_function_1.out: No such file or directory ok create_type .. failed create_table .. ok create_function_2 .. ./regress.sh[116]: sql/create_function_2.sql: cannot open: No such file or directory diff: expected/create_function_2.out: No such file or directory diff: results/create_function_2.out: No such file or directory ok copy .. ./regress.sh[116]: sql/copy.sql: cannot open: No such file or directory diff: expected/copy.out: No such file or directory diff: results/copy.out: No such file or directory ok constraints .. ./regress.sh[116]: sql/constraints.sql: cannot open: No such file or directory diff: expected/constraints.out: No such file or directory diff: results/constraints.out: No such file or directory ok triggers .. failed create_misc .. ok create_aggregate .. ok create_operator .. failed create_index .. failed create_view .. failed sanity_check .. ok errors .. ok select .. failed select_into .. ok select_distinct .. failed select_distinct_on .. failed select_implicit .. ok select_having .. ok subselect .. ok union .. ok case .. ok join .. ok aggregates .. failed transactions .. failed random .. failed portals .. failed arrays .. ok btree_index .. failed hash_index .. failed misc .. ./regress.sh[116]: sql/misc.sql: cannot open: No such file or directory diff: expected/misc.out: No such file or directory diff: results/misc.out: No such file or directory ok select_views .. failed alter_table .. failed portals_p2 .. failed rules .. failed foreign_key .. ok limit .. failed plpgsql .. ok temp .. ok ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out To run the optional big test(s) too, type 'make bigtest' These big tests can take over an hour to complete These actually are: numeric_big rm regress.o -- Murad Nayal M.D. Ph.D. Department of Biochemistry and Molecular Biophysics College of Physicians and Surgeons of Columbia University 630 West 168th Street. New York, NY 10032 Tel: 212-305-6884 Fax: 212-305-6926
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> 1- the program that configure uses to test for namespace std is faulty.
That's not very helpful :-( --- what's wrong with it?
> 2- configure badly guesses the type of the 3rd argument to accept().
I have seen that happen on other platforms too; not clear how to fix it.
But as long as the guessed value is the right size it should work,
I would think --- unsigned int vs. int shouldn't make a difference.
Are you sure that that is the reason it wasn't working?
> 3- src/pl/tcl/Makefile has a bug. line 69 is
> CFLAGS= $(TCL_CFLAGS_OPTIMIZE)
> that clobbers all CFLAGS included previously. as a result the include
> directories, important to find tcl.h etc. will not be added to the
> options and the compilation stops here complaining that it can't locate
> tcl.h etc.
> I just changed it to
> CFLAGS+= $(TCL_CFLAGS_OPTIMIZE)
Good point, but that's no solution --- the reason that the makefile
isn't keeping the main CFLAGS is that Tcl (and hence pltcl) may be
built with a different compiler than Postgres is being built with.
The Tcl compiler may not like the other compiler's switches. I guess
we could arrange to insert just the -I switches from your
--with-includes configuration command, however.
> 4- I had to change line 8 of interfaces/odbc/isqlext.h
> from # include <isql.h>
> to # include "isql.h"
> to force the inclusion of the local isql.h
Good catch.
> now my questions: While compiling, i noticed a lot of warnings about
> pointers getting truncated etc. it seems that postgres assumes pointer
> sizes to be 32 bits. so I suppose compiling for a 64bit platform can be
> risky. Anyone have experience compiling postgres on a 64bit platform.
We do assume that "unsigned long" will hold a pointer; if that's not
true on IRIX then you're going to have troubles. There are a number
of patches known to be needed on Alphas, which are planned for
integration into the standard distribution for 7.1 --- dunno if any
of them would help on your setup.
> a lot of the regression tests also failed. some of these failures don't
> seem to be trivial (some are trivial).
It looks like you neglected to run "make all" before "make runtest".
Try that and see if it gets better...
regards, tom lane
> > I managed to compile (and sort of run) postgres 7.0 to SGI running IRIX > 6.5.7. I compiled to 64bit libraries. The problems I had were both due > errors in the configure script as well as postgres configuration files. > > configure problems: > ------------------- > 1- the program that configure uses to test for namespace std is faulty. > I had to manually add #define HAVE_NAMESPACE_STD 1 to the top of > interfaces/libpq++/pgconnection.h Can you suggest a test that does work on Irix? > > 2- configure badly guesses the type of the 3rd argument to accept(). it > decided it should be size_t (unsigned int on IRIX) while accept on IRIX > takes an int. postgres compiles, but accept never retrieves the IP > address of the connecting client (in StreamConnection() function in the > file backend/libpq/pqcomm.c). as a result no authentication can happen > and the postmaster refuses connections regardless of what is in > pg_hba.conf. the error message is usually something like > > "no pg_hba.conf entry for host localhost user postgres database > template1" > > here local host is just a default string and apparently will never match > anything in pg_hba.conf. to fix this i changed line 521 of > include/config.h > from: #define SOCKET_SIZE_TYPE size_t > to: #define SOCKET_SIZE_TYPE int Again, a suggested change? > > postgres problems > ------------------ > 3- src/pl/tcl/Makefile has a bug. line 69 is > CFLAGS= $(TCL_CFLAGS_OPTIMIZE) > that clobbers all CFLAGS included previously. as a result the include > directories, important to find tcl.h etc. will not be added to the > options and the compilation stops here complaining that it can't locate > tcl.h etc. > I just changed it to > CFLAGS+= $(TCL_CFLAGS_OPTIMIZE) Changed. > > 4- I had to change line 8 of interfaces/odbc/isqlext.h > from # include <isql.h> > to # include "isql.h" > to force the inclusion of the local isql.h Changed. Will appear in 7.0.1. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > 3- src/pl/tcl/Makefile has a bug. line 69 is > > CFLAGS= $(TCL_CFLAGS_OPTIMIZE) > > that clobbers all CFLAGS included previously. as a result the include > > directories, important to find tcl.h etc. will not be added to the > > options and the compilation stops here complaining that it can't locate > > tcl.h etc. > > I just changed it to > > CFLAGS+= $(TCL_CFLAGS_OPTIMIZE) > > Good point, but that's no solution --- the reason that the makefile > isn't keeping the main CFLAGS is that Tcl (and hence pltcl) may be > built with a different compiler than Postgres is being built with. > The Tcl compiler may not like the other compiler's switches. I guess > we could arrange to insert just the -I switches from your > --with-includes configuration command, however. Tom, do you want his verion in Makefile, or the original? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Good point, but that's no solution --- the reason that the makefile
>> isn't keeping the main CFLAGS is that Tcl (and hence pltcl) may be
>> built with a different compiler than Postgres is being built with.
>> The Tcl compiler may not like the other compiler's switches. I guess
>> we could arrange to insert just the -I switches from your
>> --with-includes configuration command, however.
> Tom, do you want his verion in Makefile, or the original?
I'm working on it now --- need to fix configure to export a list of
just the -I switches, so we can include those into the pltcl build.
plperl may have the same problem, haven't looked yet.
There is a potential problem in this area that I've actually seen
happen, but don't know a way around: the two compilers may have
different default search paths. For example, on my system gcc includes
/usr/local/include in its default search path, but the system cc does
not. So, if you've built Tcl with system cc, and installed it in
/usr/local, and then try to build Postgres with gcc and --with-tcl,
everything goes fine until you get to pltcl, whereupon it falls over
because pltcl will be built with cc and cc doesn't find tcl.h.
That will still happen with this fix. The only way to build that
configuration successfully is to explicitly say
"--with-includes=/usr/local/include --with-libs=/usr/local/lib".
Arguably this is a bug in Tcl's tclConfig.sh, since it probably ought to
put "-I/usr/local/include" into its own CFLAGS settings when it's been
built that way ... but it doesn't ...
I don't have an answer to solving that problem automatically,
but I thought it'd be good to mention it for the archives.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> 2- configure badly guesses the type of the 3rd argument to accept(). it
>> decided it should be size_t (unsigned int on IRIX) while accept on IRIX
>> takes an int.
> Again, a suggested change?
This is something that's been bugging me for a while; the problem on
most platforms is that int vs unsigned int parameter will only draw a
warning from the compiler, and autoconf's TRY_COMPILE macro is only able
to detect outright errors.
I looked at the standard Autoconf macros just now, and found an example
that may give us the right solution: instead of trying to see whether
a call of accept with "int" or "unsigned int" parameter works, include
<sys/socket.h> and then write an "extern" declaration for accept with
the parameters we think it should have. This relies on the hope that
if the compiler sees two declarations for accept with different
parameter lists, it'll generate an error and not just a warning.
It seems like that should work at least as well, maybe better, as what
we're doing now --- but it's not the kind of change that I want to shove
into 7.0.1 with no beta testing! Probably we should introduce it early
in the 7.1 cycle instead, and see if anyone reports problems.
regards, tom lane
Bruce Momjian wrote:
>
> >
> > I managed to compile (and sort of run) postgres 7.0 to SGI running IRIX
> > 6.5.7. I compiled to 64bit libraries. The problems I had were both due
> > errors in the configure script as well as postgres configuration files.
> >
> > configure problems:
> > -------------------
> > 1- the program that configure uses to test for namespace std is faulty.
> > I had to manually add #define HAVE_NAMESPACE_STD 1 to the top of
> > interfaces/libpq++/pgconnection.h
>
> Can you suggest a test that does work on Irix?
>
the current test is:
#line 1680 "configure"
#include "confdefs.h"
#include <stdio.h>
#include <stdlib.h>
using namespace std;
int main() {
; return 0; }
it fails with the message:
"configure", line 1683: error(3173): name must be a namespace name
using namespace std;
you just need to add a header file that contains elements of the C++
standard library defined in std. not all C++ standard library that comes
with the SGI C++ compiler are in defined in std. for example iostream
stuff are not in std. however string is. so just include the string
header file in the program. This compiles fine with CC:
#line 1680 "configure"
#include "confdefs.h"
#include <stdio.h>
#include <stdlib.h>
#include <string>
using namespace std;
int main() {
; return 0; }
the SGI compiler puts the std library in header files that don't end in
".h". same header file ending in ".h" will have declarations in the
global name space.
Regards
--
Murad Nayal M.D. Ph.D.
Department of Biochemistry and Molecular Biophysics
College of Physicians and Surgeons of Columbia University
630 West 168th Street. New York, NY 10032
Tel: 212-305-6884 Fax: 212-305-6926
Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> 2- configure badly guesses the type of the 3rd argument to accept(). it > >> decided it should be size_t (unsigned int on IRIX) while accept on IRIX > >> takes an int. > > > Again, a suggested change? > > This is something that's been bugging me for a while; the problem on > most platforms is that int vs unsigned int parameter will only draw a > warning from the compiler, and autoconf's TRY_COMPILE macro is only able > to detect outright errors. > > I looked at the standard Autoconf macros just now, and found an example > that may give us the right solution: instead of trying to see whether > a call of accept with "int" or "unsigned int" parameter works, include > <sys/socket.h> and then write an "extern" declaration for accept with > the parameters we think it should have. This relies on the hope that > if the compiler sees two declarations for accept with different > parameter lists, it'll generate an error and not just a warning. sys/socket is already included in the test program. and yet all I get from the cc compiler is a warning!!! But here is a bit of trivia that I found. the CC compiler (C++ on SGI) won't take it and will generate an error. I am not sure obviously if this is to be expected of other C++ compilers. This particular warning message on my compiler has the number 1164. you can turn warning messages to error conditions using the flag -diag_error message_number. So while cc conftest.c in this case generates a warning. cc -diag_error 1164 conftest.c will generate an error. Again I don't know if this feature is common in other compilers. Murad -- Murad Nayal M.D. Ph.D. Department of Biochemistry and Molecular Biophysics College of Physicians and Surgeons of Columbia University 630 West 168th Street. New York, NY 10032 Tel: 212-305-6884 Fax: 212-305-6926
Tom Lane wrote: > > Murad Nayal <murad@godel.bioc.columbia.edu> writes: > > 1- the program that configure uses to test for namespace std is faulty. > > That's not very helpful :-( --- what's wrong with it? > > > 2- configure badly guesses the type of the 3rd argument to accept(). > > I have seen that happen on other platforms too; not clear how to fix it. > But as long as the guessed value is the right size it should work, > I would think --- unsigned int vs. int shouldn't make a difference. > Are you sure that that is the reason it wasn't working? > I am actually pretty sure that giving accept a size_t addrlen (in this case) is causing accept to not copy the client address over (at least not copy it to the right place!). I was a little bit inaccurate in my statement earlier though. size_t is unsigned int when compiling in 32bit mode. however it seems to be unsigned long (8 bytes) when compiling in 64bit mode, while int is still 4 bytes. so that seems consistent with what you said. I was trying to compile postgres in 64 because I would like to integrate it with the rest of my libraries which I usually compile in 64bit mode. I suppose I only need the frontend to be binary compatible with my code (libpq?) but I can only imagine the hassle I could get into trying to compile the front end in 64 and the backend separately in n32. I am going to repeat the regression tests just to make sure I used gmake all in regress and will report back. Regards -- Murad Nayal M.D. Ph.D. Department of Biochemistry and Molecular Biophysics College of Physicians and Surgeons of Columbia University 630 West 168th Street. New York, NY 10032 Tel: 212-305-6884 Fax: 212-305-6926
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> I was a little bit inaccurate in my
> statement earlier though. size_t is unsigned int when compiling in 32bit
> mode. however it seems to be unsigned long (8 bytes) when compiling in
> 64bit mode, while int is still 4 bytes.
OK, in that case I'd believe it's a critical issue.
I think the conflicting-declarations trick I mentioned earlier will let
us build a more reliable configure test for this, but as I said I don't
want to risk shoving it into 7.0.* --- this is the sort of thing that
you can't trust until it's been through some beta testing on a variety
of platforms. We'll put it in 7.1 and see what happens. In the
meantime you'll have to patch config.h by hand...
regards, tom lane
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> you just need to add a header file that contains elements of the C++
> standard library defined in std. not all C++ standard library that comes
> with the SGI C++ compiler are in defined in std. for example iostream
> stuff are not in std. however string is. so just include the string
> header file in the program.
You realize, of course, that we don't want to depend on <string>
being there either ;-)
But I suppose we could swap the order of the tests, and then
include <string> into the namespace test if we've found it.
Will do...
regards, tom lane
> > It looks like you neglected to run "make all" before "make runtest". > Try that and see if it gets better... ok, you were right. apparently on my last cycle of gmake clean/gmake all I dropped the gmake all. On a brand new installation (it is amazing how fast these things go once you figure out all the necessary tweaks :-) ) the testing output does get better. Still I am getting a lot of fails and most of them seem nontrivial. regress.out is below. I ran the sequential tests since I actually needed to insert a line in pg_hba.conf to allow my host to connect: the line host all 127.0.0.1 255.255.255.255 trust wasn't enough for some reason, I had to specify my IP address in an additional line for the authentication to work. host all 156.111.96.29 255.255.255.255 trust hence, I had to run the postmaster on the modified configuration before the tests. anyway, please let me know if failing of any of these tests is particularly ominous. the regressions.diffs, the postmaster output or the gmake output are also available if anybody is interested. Thanks cat regress.out =============== Notes... ================= postmaster must already be running for the regression tests to succeed. The time zone is set to PST8PDT for these tests by the client frontend. Please report any apparent problems to ports@postgresql.org See regress/README for more information. =============== dropping old regression database... ================= ERROR: DROP DATABASE: Database "regression" does not exist dropdb: database removal failed =============== creating new regression database... ================= CREATE DATABASE =============== installing languages... ================= installing PL/pgSQL .. ok =============== running regression queries... ================= boolean .. ok char .. ok name .. ok varchar .. ok text .. ok int2 .. failed int4 .. failed int8 .. failed oid .. ok float4 .. ok float8 .. ok numeric .. ok strings .. failed numerology .. failed point .. ok lseg .. ok box .. ok path .. ok polygon .. ok circle .. ok interval .. ok timestamp .. ok reltime .. ok tinterval .. failed inet .. ok comments .. ok oidjoins .. failed type_sanity .. failed opr_sanity .. failed abstime .. failed geometry .. failed horology .. failed create_function_1 .. ok create_type .. ok create_table .. ok create_function_2 .. ok copy .. ok constraints .. ok triggers .. ok create_misc .. ok create_aggregate .. ok create_operator .. ok create_index .. ok create_view .. ok sanity_check .. ok errors .. ok select .. ok select_into .. ok select_distinct .. ok select_distinct_on .. ok select_implicit .. ok select_having .. ok subselect .. ok union .. ok case .. ok join .. ok aggregates .. ok transactions .. ok random .. ok portals .. ok arrays .. ok btree_index .. ok hash_index .. ok misc .. ok select_views .. ok alter_table .. ok portals_p2 .. ok rules .. failed foreign_key .. ok limit .. ok plpgsql .. ok temp .. ok -- Murad Nayal M.D. Ph.D. Department of Biochemistry and Molecular Biophysics College of Physicians and Surgeons of Columbia University 630 West 168th Street. New York, NY 10032 Tel: 212-305-6884 Fax: 212-305-6926
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> the testing output does get better. Still I am getting a lot of fails
> and most of them seem nontrivial.
I agree. Hard to tell with this level of detail, but you show many
failures in tests that aren't particularly platform-sensitive.
I think there are some real bugs to be worked out...
regards, tom lane