FAQ
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

Search Discussions

  • Tom Lane at May 22, 2000 at 11:36 pm

    Murad Nayal 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
  • Bruce Momjian at May 23, 2000 at 12:00 am

    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
  • Murad Nayal at May 23, 2000 at 3:32 am

    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
  • Tom Lane at May 23, 2000 at 3:59 am

    Murad Nayal 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 at May 23, 2000 at 4:35 am

    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
  • Tom Lane at May 23, 2000 at 4:59 am

    Murad Nayal 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
  • Bruce Momjian at May 22, 2000 at 11:57 pm

    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
  • Tom Lane at May 23, 2000 at 1:12 am

    Bruce Momjian 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
  • Murad Nayal at May 23, 2000 at 3:17 am

    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 at May 23, 2000 at 2:57 am

    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 at May 23, 2000 at 4:03 am

    Murad Nayal 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedMay 22, '00 at 10:45p
activeMay 23, '00 at 4:59a
posts12
users3
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase