Re: [HACKERS] Last call? - Mailing list pgsql-hackers

From Frank Ridderbusch
Subject Re: [HACKERS] Last call?
Date
Msg-id 13879.38302.730116.172589@otter
Whole thread Raw
In response to Re: [HACKERS] Last call?  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
Responses Re: [HACKERS] Last call?
List pgsql-hackers
Hi,

here are my results for building beta3 on MIPS SVR4. The regression
tests are as good as they can be. There are a couple of changes
necessary, which I've described in a little README, which I've
appended below.

Thomas G. Lockhart writes:> Would like to get reports running the Postgres v6.4beta on these> remaining platforms in
thenext couple of days:> > > _  DGUX (needs a new maintainer)> > _  IRIX 6.x (Andrew?)> > _  Digital 4.0> > _  linux
2.0.xAlpha (needs some work; someone have patches?)> > _  NetBSD 1.3 VAX (Tom H's machine is down; anyone else?)> > _
SCO(Billy, have you had any luck with this?)> > _  Solaris x86 (Marc?)> > _  SunOS 4.1.4 Sparc (Tatsuo?)> > _  SVR4 4.4
m88k>> TIA> >                      - Tom> > 
 

Readme for building Postgresql 6.4 on Siemens RM Systems
========================================================

1. Overview
===========

This README describes the necessary steps to build the Postgresql
database system on SINIX/Reliant UNIX. Reliant UNIX (previously called
SINIX) is a SVR4 variant, which runs on Siemens RM400/RM600 servers.
These servers use the MIPS R3000/R4400/R10000 family of processors.

The following description is based on SINIX-P 5.42A10 running on a
RM600-xx with 4 processors (both the machine and the operating system
are pretty old, therefore your milage my vary on newer os versions).

2. Building
===========

You can not use the GCC version for this platform (2.7.2.3 from
ftp://ftp.mch.sni.de/sni/mr/pd/gnu). But you have to install it
anyway, since the GCC cpp must be used during an intermediate step,
when header files are produced. You have to use the Siemens
C-compilations environment (I used CDS 1.1A00) for the actual
compilation process. Reason is, that the postgresql backend is build
with several 'ld -R' passes. The linker expects the symbols to be
sorted in ELF object file, which this GCC port apparently does not do.

Apart from flex, bison, you also need GNU awk. Awk is used in
genbki.sh and the expression used in the shell script appears to be
too complex for the system awk. Therefore install GNU awk and make
sure, that this version is found before the system awk (ordering of
PATH variable).

I configured with
 ./configure --with-template=svr4 \             --prefix=/home/tools/pgsql-6.4 \
--with-includes=/home/tools/include\             --with-libraries=/home/tools/lib
 

You might be tempted to run configure with the additional argument
--with-CC='cc -W0' to activate the native C-compiler. However, when I
did this, compilation stopped with this error message.
 cc -W0 -I../../../include -I../../../backend   -I/home/tools/include -I../..    -c istrat.c -o istrat.o istrat.c
496:[error]:     2324 Undefined: 'F_OIDEQ'      2086 c1: errors: 1, warnings: 15
 

After that the following changes are necessary (the changes are
explicitly listed, since the changes might not be compatible with
other SVR4 platforms, which use the same files):

o    Add -lsocket before -lnsl in Makefile.global

o    edit Makefile.port and extend LDFLAGS with -lmutex, so that it    like this
        LDFLAGS+= -lmutex -lc /usr/ucblib/libucb.a -LD-Blargedynsym
    And add a line to enable the native C-compiler
        CUSTOM_CC = cc -W0 -O2

o    configure does not correctly reqognize the number of arguments    for gettimeofday. Therefore 'undef'
HAVE_GETTIMEOFDAY_2_ARGS.

o    These two patches are necessary to fix a compiler bug.
    In backend/utils/adt/date.c around line 179 change
      EncodeTimeSpan(tm, 0, DateStyle, buf);
    to
      EncodeTimeSpan(tm, 0.0, DateStyle, buf);
    and in backend/utils/adt/dt.c around line 349 and 359 change
      tm2datetime(&tt, 0, NULL, &dt);
    to
      tm2datetime(&tt, 0.0, NULL, &dt);
    Patches in diff -u form are appended below.

o    In src/backend/port/Makefile remove the 'strcasecmp.o'.

3. Restrictions
===============

Connecting to the backend via unix domain sockets does not work and
the 64bit data type is not supported. Otherwise the regression test
shows no remarkable differences.

4. Patches
==========

Please remove the first blank column, if you apply the patches.
diff -u src/backend/utils/adt/date.c~ src/backend/utils/adt/date.c--- src/backend/utils/adt/date.c~      Wed Oct 28
20:43:421998+++ src/backend/utils/adt/date.c       Wed Oct 28 20:43:42 1998@@ -176,7 +176,7 @@        else        {
          reltime2tm(time, tm);-              EncodeTimeSpan(tm, 0, DateStyle, buf);+              EncodeTimeSpan(tm,
0.0,DateStyle, buf);        }
 
        result = palloc(strlen(buf) + 1);diff -u src/backend/utils/adt/dt.c~ src/backend/utils/adt/dt.c---
src/backend/utils/adt/dt.c~       Wed Oct 28 20:45:42 1998+++ src/backend/utils/adt/dt.c Wed Oct 28 20:45:42 1998@@
-346,7+346,7 @@        if (DATETIME_IS_CURRENT(dt))        {                GetCurrentTime(&tt);-
tm2datetime(&tt,0, NULL, &dt);+              tm2datetime(&tt, 0.0, NULL, &dt);                dt = dt2local(dt,
-CTimeZone);
 #ifdef DATEDEBUG@@ -356,7 +356,7 @@        else        {                                                      /* if
(DATETIME_IS_EPOCH(dt1))*/                GetEpochTime(&tt);-              tm2datetime(&tt, 0, NULL, &dt);+
tm2datetime(&tt, 0.0, NULL, &dt); #ifdef DATEDEBUG                printf("SetDateTime- epoch time is %f\n", dt);
#endif

MfG/Regards
--    /====                         Siemens AG   /    Ridderbusch        / ,   ICP CS XS QM4  /
/./  Heinz Nixdorf Ring /=== /,== ,===/  /,==,  //    33106 Paderborn, Germany/    //   /   /  //   / / \   Tel.: (49)
5251-8-15211
/    /     `==/\ /    / /   \ Email: ridderbusch.pad@sni.de

Since I have taken all the Gates out of my computer, it finally works!!


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Another bug in pg_operator.h
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Another bug in pg_operator.h