Thread: 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
> > 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
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
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