Обсуждение: IRIX6.5 Patch to Postgres 6.5 Beta (Snap Jun 7)

Поиск
Список
Период
Сортировка

IRIX6.5 Patch to Postgres 6.5 Beta (Snap Jun 7)

От
Mark Dalphin
Дата:
Hi,

The following is an excessively wordy "note" on getting Postgresql 6.5
Beta (Jun 7 snapshot) to compile on an SGI IRIX 6.5 (with notes for
some other versions of IRIX). It is long in the hopes that it may help
the developers make a cleanly installing versions. I have included a
patch file at the end for the current source tree which patches the
Jun 7 tree to make a clean install on my SGI.

Additional comment: The file, doc/FAQ_Irix, seems to have been
corrupted with non-FAQ material.

----------------------------------------------------------------------
Notes on how my SGI may differ from the ordinary SGI

1) I have installed the SGI additional material, known as
"freeware". This material includes a newer version of Perl, plus many
GNU utilities, including an "install" program. I have found that much
of this material is very helpful when installing public domain
software.

2) SGI places some of their files in unusual places. I was never able
to get any "free" Tcl/Tk programs to compile until I tracked down and
unlinked the SGI versions of Tcl/Tk and installed a fresh and more
recent version of Tcl/Tk in the more normal /usr/local.

3) I installed the GNU "readline" libraries in /usr/local.

4) The newer version of Perl is located in the /usr/freeware directory
tree created by SGI. This is not a problem when installing Perl
modules; Perl seems quite good about knowing where to find its
libraries, etc. I did, however, need to re-link some pointers from
/usr/bin/perl, /usr/sbin/perl and and a link from /usr/local/bin/perl
to /usr/freeware/bin/perl to make all modules & programs happy.

---------------------------------------------------------------------
I have not got much experience with the C-compiler under IRIX6.5 and
its many options, but I have read the manual. For those who run into
porting problems under different versions of IRIX6.x, I mention here
my understanding of some of the options and why I have chosen what I
have chosen. This information is from the IRIS InSight Book: "MIPSpro
Compiling and Performance Tuning Guide".

To accomodate the change from 32-bit to 64-bit SGI computers, there
are now three ABIs (Application Binary Interface) formats, which is
the format output by the compilers (this takes effect with IRIX
6.1). They are NOT compatible with each other. The formats are: the
old-32-bit, the new-32-bit and the 64-bit ABIs.  The ABI you work
under is set by default, thru the file /etc/compiler.defaults. This
may be over-ridden by an environment variable. The libraries which are
linked with these different ABIs must be compatible, hence, there are
three sets of library files.

Why choose one ABI over another?  First, it may be difficult to
convert some C-programs from 32-bit to 64-bit due to assumptions about
pointer sizes. I have heard that PostgreSQL had some troubles on the
DEC Alpha for this reason. I have more recently heard that this has
been fixed.

Another problem is that 64-bit programs tend to be larger than the
32-bit ones due to memory alignment constraints. This may be
outweighed by the larger addressing space.

Why choose the new 32-bit or the old 32-bit formats? I have heard that
the new 32-bit format is faster, smaller and buggier. As I have not
been bitten by any of the bugs yet, I am happy to run with the new
32-bit mode by default.  Sometimes, one needs to use the old 32-bit
mode for compatibility with older software; for example, I am told
that Oracle releases their libraries for SGI in old 32-bit format.

Selecting the different ABIs can be done with the file
/etc/compiler.defaults, by the environment variable: SGI_ABI (set it
to: -n32, -o32, or -64) or by using a compiler option: -n32, -o32, or
-64. (The -32 option means -o32 under IRIX6.5) (Changing the options
also alters the family of mips processor for which the code is
generated.  -o32 generates for mips2 while -n32 generates for mips3 or
mips4).

When linking, the default libraries change depending upon the ABI:
        -o32 = /usr/lib /lib
        -n32 = /usr/lib32 /lib32
        -64  = /usr/lib64 /lib64

By default, the linker looks for a shared-object library first when a
library is specified, then for an archive library. (By the way, shared
objects are know as Dynamic Shared Objects, DSO, under SGI).  From the
SGI manual,

        ld foiled.o again.o -lcurses

looks for libcurses.so in /usr/lib, then in /lib, then for libcurses.a
in /usr/lib and /lib, and then, finally, for libcurses.a (only, not
the DSO) in /usr/local/lib.  When a directory containing libraries is
added to the 'cc' command, via the -L option, that directory name is
placed at the head of the default search path. Again, the linker will
then search for the DSO first and then look for the archive file format
second.

-------------------------------------------------------------------------
To compile Postgresql 6.5 Beta, snapshot June 7, under my SGI IRIX 6.5
required the following patches:

1) Alter a #definition from _ALIGN to _PGALIGN to prevent a collision
between the postgresql name and an SGI name in <sys/socket.h>.

2) Add one line to the libpq++ source. The C++ compile was failing,
complaining the the C++ type "string" was not defined. I am not a C++
programmer, however, our local expert suggested that "the latest
versions of C++ have name spaces and one must specify the default
namespace to look for names like 'string'."

We specified a namespace and libpq++ compiled smoothly. I had several
identical errors crop up while testing the libpq++ examples, but did
not pursue the solution.

3) Following the instructions in an email from Robert Bruccoleri
(bruc@acm.org; May 27, 1999 to pgsql-hackers), I added the
instructions for DSOs under SGI. I asked Robert about why he used a
Makefile.custom to include the compiler specific changes and he
commented that that was how he read the instructions in
Makefile.global. He also commented that the changes could be made to
the port file: Makefile.irix5 instead. I have not done this for fear
of breaking an earlier version of IRIX, but think it would be a good
idea in the long run. Note: I used the -n32 option while Robert used
the -o32 C-compiler option.

4) Robert Bruccoleri also suggests making 2 additional changes. The
first is a re-write of install because "install moves the sample files
from the source tree into their places. Any future compiles will then
fail." This has not happened for me, perhaps because I am using the
GNU "install" program?

The second change is to disable "nls". According to R. Bruccoleri,
"nls caused problems with NIS under IRIX 6.4". Again, this has not
(yet) been a problem for me under IRIX 6.5, although I do use NIS.

-----------------------------------------------------------------------

To make postgresql, unpack the source tree (I used the name:
postgresql-6.5Beta_Jun7).  Patch the source with the patch located at
the bottom of this message. I compiled with the following "configure":

        ./configure --with-tcl --with-perl --with-x \
                --with-CC=/usr/bin/cc --with-CXX=/usr/bin/CC \
                --with-includes=/usr/local/include \
                --with-libs=/usr/local/lib

I need to specify the /usr/local/include and /usr/local/lib for
configure to find the GNU readline library. I need to specify the CC
and CXX or configure attempts to use gcc which I also have on my
machine.

------------------------------------------------------------------------
Regression test outputs (edited):

Trivial failures of int2 and int4 due to output message wording.
Trivial failure of geometry due to rounding or signed zero (see example):
======   geometry   ======
102c102
< |(0,0)   |[(0,0),(6,6)]                |(-0,0)
---
> |(0,0)   |[(0,0),(6,6)]                |(0,0)
115c115
< |(-10,0) |[(-1000000,200),(300000,-40)]|(-9.99715942258202,15.3864610140473)
---
> |(-10,0) |[(-1000000,200),(300000,-40)]|(-9.99715942258202,15.3864610140472)


Failure of time types due to specific dates in history (see examples):
I believe these errors are due to the system time-zone information, rather
that Postgresql problems.
======   abstime   ======
25c25
<      |Sat May 10 23:59:12 1947 PST
---
>      |Sun May 11 00:59:12 1947 PDT
======   tinterval   ======
22c22
<     |["Sat May 10 23:59:12 1947 PST" "Sun Jan 14 03:14:21 1973 PST"]
---
>     |["Sun May 11 00:59:12 1947 PDT" "Sun Jan 14 03:14:21 1973 PST"]
======   horology   ======
432c432
<     |Sat May 10 23:59:12 1947 PST|1947|    5| 10|  23|    59|    12
---
>     |Sun May 11 00:59:12 1947 PDT|1947|    5| 11|   0|    59|    12
774c774
<      |05/10/1947 23:59:12.00 PST
---
>      |05/11/1947 00:59:12.00 PDT
852c852
<            |Thu 13 Jun 00:00:00 1957 PDT
---
>            |Thu 13 Jun 01:00:00 1957 PDT

------------------------------------------------------------------------

PATCH to the source directory:

To patch:
        1) gunzip -c postgresql.tar.gz | tar -xf -
        2) ln -s pgsql postgresql-6.5Beta_Jun7  # This helps apply my patch
        3) patch < this-message
        4) mv Makefile.custom postgresql-6.5Beta_Jun7/src/
        5) cd postgresql-6.5Beta_Jun7/src
        6) proceed with normal postgres: configure, make all, make install ...

diff -r -c -N postgresql-6.5Beta_Jun7/src/Makefile.custom
postgresql-6.5_IRIX6.5/src/Makefile.custom
*** postgresql-6.5Beta_Jun7/src/Makefile.custom Wed Dec 31 16:00:00 1969
--- postgresql-6.5_IRIX6.5/src/Makefile.custom  Mon Jun  7 15:02:34 1999
***************
*** 0 ****
--- 1,3 ----
+ CUSTOM_CC = cc -n32
+ LD += -n32
+ MK_NO_LORDER = 1
diff -r -c -N postgresql-6.5Beta_Jun7/src/Makefile.shlib
postgresql-6.5_IRIX6.5/src/Makefile.shlib
*** postgresql-6.5Beta_Jun7/src/Makefile.shlib  Thu May 20 00:01:15 1999
--- postgresql-6.5_IRIX6.5/src/Makefile.shlib   Mon Jun  7 15:44:34 1999
***************
*** 56,61 ****
--- 56,68 ----
  # Makefile.global (or really Makefile.port) to supply DLSUFFIX and other
  # symbols.

+ ifeq ($(PORTNAME), irix5)
+   install-shlib-dep := install-shlib
+   shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO__MINOR_VERSION)
+   LDFLAGS_SL := -shared
+   CFLAGS += $(CFLAGS_SL)
+ endif
+
  ifeq ($(PORTNAME), freebsd)
    ifdef BSD_SHLIB
      install-shlib-dep := install-shlib
diff -r -c -N postgresql-6.5Beta_Jun7/src/include/utils/memutils.h
postgresql-6.5_IRIX6.5/src/include/utils/memutils.h
*** postgresql-6.5Beta_Jun7/src/include/utils/memutils.h        Thu May 27
00:00:43 1999
--- postgresql-6.5_IRIX6.5/src/include/utils/memutils.h Mon Jun  7 16:11:55 1999
***************
*** 38,50 ****
   * ----------------
   */

! #define _ALIGN(ALIGNVAL,LEN)  (((long)(LEN) + (ALIGNVAL-1)) & ~(ALIGNVAL-1))

! #define SHORTALIGN(LEN)                       _ALIGN(ALIGNOF_SHORT, (LEN))
! #define INTALIGN(LEN)                 _ALIGN(ALIGNOF_INT, (LEN))
! #define LONGALIGN(LEN)                        _ALIGN(ALIGNOF_LONG, (LEN))
! #define DOUBLEALIGN(LEN)              _ALIGN(ALIGNOF_DOUBLE, (LEN))
! #define MAXALIGN(LEN)                 _ALIGN(MAXIMUM_ALIGNOF, (LEN))

  /*****************************************************************************
   *      oset.h --                     Fixed format ordered set
definitions.                            *
--- 38,50 ----
   * ----------------
   */

! #define _PGALIGN(ALIGNVAL,LEN)        (((long)(LEN) + (ALIGNVAL-1)) &
~(ALIGNVAL-1))

! #define SHORTALIGN(LEN)                       _PGALIGN(ALIGNOF_SHORT, (LEN))
! #define INTALIGN(LEN)                 _PGALIGN(ALIGNOF_INT, (LEN))
! #define LONGALIGN(LEN)                        _PGALIGN(ALIGNOF_LONG, (LEN))
! #define DOUBLEALIGN(LEN)              _PGALIGN(ALIGNOF_DOUBLE, (LEN))
! #define MAXALIGN(LEN)                 _PGALIGN(MAXIMUM_ALIGNOF, (LEN))

  /*****************************************************************************
   *      oset.h --                     Fixed format ordered set
definitions.                            *
diff -r -c -N postgresql-6.5Beta_Jun7/src/interfaces/libpq++/pgconnection.h
postgresql-6.5_IRIX6.5/src/interfaces/libpq++/pgconnection.h
*** postgresql-6.5Beta_Jun7/src/interfaces/libpq++/pgconnection.h       Sun May
23 00:01:46 1999
--- postgresql-6.5_IRIX6.5/src/interfaces/libpq++/pgconnection.h        Mon Jun
7 16:17:40 1999
***************
*** 27,32 ****
--- 27,33 ----
  #include "libpq-fe.h"
  }

+ using namespace std;

  // ****************************************************************
  //


--
Mark Dalphin                          email: mdalphin@amgen.com
Mail Stop: 29-2-A                     phone: +1-805-447-4951 (work)
One Amgen Center Drive                       +1-805-375-0680 (home)
Thousand Oaks, CA 91320                 fax: +1-805-499-9955 (work)

Bad FAQ file

От
Thomas Lockhart
Дата:
> Additional comment: The file, doc/FAQ_Irix, seems to have
> been corrupted with non-FAQ material.

I see that here too. Bruce, what happened to the FAQ? Are the other
ones OK, or did they get overwritten too? I vaguely recall that this
happened during the last release too...

                    - Thomas

--
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Re: Bad FAQ file

От
Bruce Momjian
Дата:
> > Additional comment: The file, doc/FAQ_Irix, seems to have
> > been corrupted with non-FAQ material.
>
> I see that here too. Bruce, what happened to the FAQ? Are the other
> ones OK, or did they get overwritten too? I vaguely recall that this
> happened during the last release too...

Yes, I do this regularly.  I will fix it as soon as www.postgresql.org
can be used.  It looks down right now.


--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Re: [PORTS] Re: Bad FAQ file

От
Bruce Momjian
Дата:
> > > Additional comment: The file, doc/FAQ_Irix, seems to have
> > > been corrupted with non-FAQ material.
> >
> > I see that here too. Bruce, what happened to the FAQ? Are the other
> > ones OK, or did they get overwritten too? I vaguely recall that this
> > happened during the last release too...
>
> Yes, I do this regularly.  I will fix it as soon as www.postgresql.org
> can be used.  It looks down right now.
>

Done.
--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Re: Bad FAQ file

От
Bruce Momjian
Дата:
Fixed.


> > Additional comment: The file, doc/FAQ_Irix, seems to have
> > been corrupted with non-FAQ material.
>
> I see that here too. Bruce, what happened to the FAQ? Are the other
> ones OK, or did they get overwritten too? I vaguely recall that this
> happened during the last release too...
>
>                     - Thomas
>
> --
> Thomas Lockhart                lockhart@alumni.caltech.edu
> South Pasadena, California
>


--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Re: [PORTS] IRIX6.5 Patch to Postgres 6.5 Beta (Snap Jun 7)

От
Bruce Momjian
Дата:

I have applied the Makefile.shlib that you supplied.  The others were
dealt with already.  Your Makefile.custom does not apply to the
distribution files.


> Hi,
>
> The following is an excessively wordy "note" on getting Postgresql 6.5
> Beta (Jun 7 snapshot) to compile on an SGI IRIX 6.5 (with notes for
> some other versions of IRIX). It is long in the hopes that it may help
> the developers make a cleanly installing versions. I have included a
> patch file at the end for the current source tree which patches the
> Jun 7 tree to make a clean install on my SGI.
>
> Additional comment: The file, doc/FAQ_Irix, seems to have been
> corrupted with non-FAQ material.
>
> ----------------------------------------------------------------------
> Notes on how my SGI may differ from the ordinary SGI
>
> 1) I have installed the SGI additional material, known as
> "freeware". This material includes a newer version of Perl, plus many
> GNU utilities, including an "install" program. I have found that much
> of this material is very helpful when installing public domain
> software.
>
> 2) SGI places some of their files in unusual places. I was never able
> to get any "free" Tcl/Tk programs to compile until I tracked down and
> unlinked the SGI versions of Tcl/Tk and installed a fresh and more
> recent version of Tcl/Tk in the more normal /usr/local.
>
> 3) I installed the GNU "readline" libraries in /usr/local.
>
> 4) The newer version of Perl is located in the /usr/freeware directory
> tree created by SGI. This is not a problem when installing Perl
> modules; Perl seems quite good about knowing where to find its
> libraries, etc. I did, however, need to re-link some pointers from
> /usr/bin/perl, /usr/sbin/perl and and a link from /usr/local/bin/perl
> to /usr/freeware/bin/perl to make all modules & programs happy.
>
> ---------------------------------------------------------------------
> I have not got much experience with the C-compiler under IRIX6.5 and
> its many options, but I have read the manual. For those who run into
> porting problems under different versions of IRIX6.x, I mention here
> my understanding of some of the options and why I have chosen what I
> have chosen. This information is from the IRIS InSight Book: "MIPSpro
> Compiling and Performance Tuning Guide".
>
> To accomodate the change from 32-bit to 64-bit SGI computers, there
> are now three ABIs (Application Binary Interface) formats, which is
> the format output by the compilers (this takes effect with IRIX
> 6.1). They are NOT compatible with each other. The formats are: the
> old-32-bit, the new-32-bit and the 64-bit ABIs.  The ABI you work
> under is set by default, thru the file /etc/compiler.defaults. This
> may be over-ridden by an environment variable. The libraries which are
> linked with these different ABIs must be compatible, hence, there are
> three sets of library files.
>
> Why choose one ABI over another?  First, it may be difficult to
> convert some C-programs from 32-bit to 64-bit due to assumptions about
> pointer sizes. I have heard that PostgreSQL had some troubles on the
> DEC Alpha for this reason. I have more recently heard that this has
> been fixed.
>
> Another problem is that 64-bit programs tend to be larger than the
> 32-bit ones due to memory alignment constraints. This may be
> outweighed by the larger addressing space.
>
> Why choose the new 32-bit or the old 32-bit formats? I have heard that
> the new 32-bit format is faster, smaller and buggier. As I have not
> been bitten by any of the bugs yet, I am happy to run with the new
> 32-bit mode by default.  Sometimes, one needs to use the old 32-bit
> mode for compatibility with older software; for example, I am told
> that Oracle releases their libraries for SGI in old 32-bit format.
>
> Selecting the different ABIs can be done with the file
> /etc/compiler.defaults, by the environment variable: SGI_ABI (set it
> to: -n32, -o32, or -64) or by using a compiler option: -n32, -o32, or
> -64. (The -32 option means -o32 under IRIX6.5) (Changing the options
> also alters the family of mips processor for which the code is
> generated.  -o32 generates for mips2 while -n32 generates for mips3 or
> mips4).
>
> When linking, the default libraries change depending upon the ABI:
>         -o32 = /usr/lib /lib
>         -n32 = /usr/lib32 /lib32
>         -64  = /usr/lib64 /lib64
>
> By default, the linker looks for a shared-object library first when a
> library is specified, then for an archive library. (By the way, shared
> objects are know as Dynamic Shared Objects, DSO, under SGI).  From the
> SGI manual,
>
>         ld foiled.o again.o -lcurses
>
> looks for libcurses.so in /usr/lib, then in /lib, then for libcurses.a
> in /usr/lib and /lib, and then, finally, for libcurses.a (only, not
> the DSO) in /usr/local/lib.  When a directory containing libraries is
> added to the 'cc' command, via the -L option, that directory name is
> placed at the head of the default search path. Again, the linker will
> then search for the DSO first and then look for the archive file format
> second.
>
> -------------------------------------------------------------------------
> To compile Postgresql 6.5 Beta, snapshot June 7, under my SGI IRIX 6.5
> required the following patches:
>
> 1) Alter a #definition from _ALIGN to _PGALIGN to prevent a collision
> between the postgresql name and an SGI name in <sys/socket.h>.
>
> 2) Add one line to the libpq++ source. The C++ compile was failing,
> complaining the the C++ type "string" was not defined. I am not a C++
> programmer, however, our local expert suggested that "the latest
> versions of C++ have name spaces and one must specify the default
> namespace to look for names like 'string'."
>
> We specified a namespace and libpq++ compiled smoothly. I had several
> identical errors crop up while testing the libpq++ examples, but did
> not pursue the solution.
>
> 3) Following the instructions in an email from Robert Bruccoleri
> (bruc@acm.org; May 27, 1999 to pgsql-hackers), I added the
> instructions for DSOs under SGI. I asked Robert about why he used a
> Makefile.custom to include the compiler specific changes and he
> commented that that was how he read the instructions in
> Makefile.global. He also commented that the changes could be made to
> the port file: Makefile.irix5 instead. I have not done this for fear
> of breaking an earlier version of IRIX, but think it would be a good
> idea in the long run. Note: I used the -n32 option while Robert used
> the -o32 C-compiler option.
>
> 4) Robert Bruccoleri also suggests making 2 additional changes. The
> first is a re-write of install because "install moves the sample files
> from the source tree into their places. Any future compiles will then
> fail." This has not happened for me, perhaps because I am using the
> GNU "install" program?
>
> The second change is to disable "nls". According to R. Bruccoleri,
> "nls caused problems with NIS under IRIX 6.4". Again, this has not
> (yet) been a problem for me under IRIX 6.5, although I do use NIS.
>
> -----------------------------------------------------------------------
>
> To make postgresql, unpack the source tree (I used the name:
> postgresql-6.5Beta_Jun7).  Patch the source with the patch located at
> the bottom of this message. I compiled with the following "configure":
>
>         ./configure --with-tcl --with-perl --with-x \
>                 --with-CC=/usr/bin/cc --with-CXX=/usr/bin/CC \
>                 --with-includes=/usr/local/include \
>                 --with-libs=/usr/local/lib
>
> I need to specify the /usr/local/include and /usr/local/lib for
> configure to find the GNU readline library. I need to specify the CC
> and CXX or configure attempts to use gcc which I also have on my
> machine.
>
> ------------------------------------------------------------------------
> Regression test outputs (edited):
>
> Trivial failures of int2 and int4 due to output message wording.
> Trivial failure of geometry due to rounding or signed zero (see example):
> ======   geometry   ======
> 102c102
> < |(0,0)   |[(0,0),(6,6)]                |(-0,0)
> ---
> > |(0,0)   |[(0,0),(6,6)]                |(0,0)
> 115c115
> < |(-10,0) |[(-1000000,200),(300000,-40)]|(-9.99715942258202,15.3864610140473)
> ---
> > |(-10,0) |[(-1000000,200),(300000,-40)]|(-9.99715942258202,15.3864610140472)
>
>
> Failure of time types due to specific dates in history (see examples):
> I believe these errors are due to the system time-zone information, rather
> that Postgresql problems.
> ======   abstime   ======
> 25c25
> <      |Sat May 10 23:59:12 1947 PST
> ---
> >      |Sun May 11 00:59:12 1947 PDT
> ======   tinterval   ======
> 22c22
> <     |["Sat May 10 23:59:12 1947 PST" "Sun Jan 14 03:14:21 1973 PST"]
> ---
> >     |["Sun May 11 00:59:12 1947 PDT" "Sun Jan 14 03:14:21 1973 PST"]
> ======   horology   ======
> 432c432
> <     |Sat May 10 23:59:12 1947 PST|1947|    5| 10|  23|    59|    12
> ---
> >     |Sun May 11 00:59:12 1947 PDT|1947|    5| 11|   0|    59|    12
> 774c774
> <      |05/10/1947 23:59:12.00 PST
> ---
> >      |05/11/1947 00:59:12.00 PDT
> 852c852
> <            |Thu 13 Jun 00:00:00 1957 PDT
> ---
> >            |Thu 13 Jun 01:00:00 1957 PDT
>
> ------------------------------------------------------------------------
>
> PATCH to the source directory:
>
> To patch:
>         1) gunzip -c postgresql.tar.gz | tar -xf -
>         2) ln -s pgsql postgresql-6.5Beta_Jun7  # This helps apply my patch
>         3) patch < this-message
>         4) mv Makefile.custom postgresql-6.5Beta_Jun7/src/
>         5) cd postgresql-6.5Beta_Jun7/src
>         6) proceed with normal postgres: configure, make all, make install ...
>
> diff -r -c -N postgresql-6.5Beta_Jun7/src/Makefile.custom
> postgresql-6.5_IRIX6.5/src/Makefile.custom
> *** postgresql-6.5Beta_Jun7/src/Makefile.custom Wed Dec 31 16:00:00 1969
> --- postgresql-6.5_IRIX6.5/src/Makefile.custom  Mon Jun  7 15:02:34 1999
> ***************
> *** 0 ****
> --- 1,3 ----
> + CUSTOM_CC = cc -n32
> + LD += -n32
> + MK_NO_LORDER = 1
> diff -r -c -N postgresql-6.5Beta_Jun7/src/Makefile.shlib
> postgresql-6.5_IRIX6.5/src/Makefile.shlib
> *** postgresql-6.5Beta_Jun7/src/Makefile.shlib  Thu May 20 00:01:15 1999
> --- postgresql-6.5_IRIX6.5/src/Makefile.shlib   Mon Jun  7 15:44:34 1999
> ***************
> *** 56,61 ****
> --- 56,68 ----
>   # Makefile.global (or really Makefile.port) to supply DLSUFFIX and other
>   # symbols.
>
> + ifeq ($(PORTNAME), irix5)
> +   install-shlib-dep := install-shlib
> +   shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO__MINOR_VERSION)
> +   LDFLAGS_SL := -shared
> +   CFLAGS += $(CFLAGS_SL)
> + endif
> +
>   ifeq ($(PORTNAME), freebsd)
>     ifdef BSD_SHLIB
>       install-shlib-dep := install-shlib
> diff -r -c -N postgresql-6.5Beta_Jun7/src/include/utils/memutils.h
> postgresql-6.5_IRIX6.5/src/include/utils/memutils.h
> *** postgresql-6.5Beta_Jun7/src/include/utils/memutils.h        Thu May 27
> 00:00:43 1999
> --- postgresql-6.5_IRIX6.5/src/include/utils/memutils.h Mon Jun  7 16:11:55 1999
> ***************
> *** 38,50 ****
>    * ----------------
>    */
>
> ! #define _ALIGN(ALIGNVAL,LEN)  (((long)(LEN) + (ALIGNVAL-1)) & ~(ALIGNVAL-1))
>
> ! #define SHORTALIGN(LEN)                       _ALIGN(ALIGNOF_SHORT, (LEN))
> ! #define INTALIGN(LEN)                 _ALIGN(ALIGNOF_INT, (LEN))
> ! #define LONGALIGN(LEN)                        _ALIGN(ALIGNOF_LONG, (LEN))
> ! #define DOUBLEALIGN(LEN)              _ALIGN(ALIGNOF_DOUBLE, (LEN))
> ! #define MAXALIGN(LEN)                 _ALIGN(MAXIMUM_ALIGNOF, (LEN))
>
>   /*****************************************************************************
>    *      oset.h --                     Fixed format ordered set
> definitions.                            *
> --- 38,50 ----
>    * ----------------
>    */
>
> ! #define _PGALIGN(ALIGNVAL,LEN)        (((long)(LEN) + (ALIGNVAL-1)) &
> ~(ALIGNVAL-1))
>
> ! #define SHORTALIGN(LEN)                       _PGALIGN(ALIGNOF_SHORT, (LEN))
> ! #define INTALIGN(LEN)                 _PGALIGN(ALIGNOF_INT, (LEN))
> ! #define LONGALIGN(LEN)                        _PGALIGN(ALIGNOF_LONG, (LEN))
> ! #define DOUBLEALIGN(LEN)              _PGALIGN(ALIGNOF_DOUBLE, (LEN))
> ! #define MAXALIGN(LEN)                 _PGALIGN(MAXIMUM_ALIGNOF, (LEN))
>
>   /*****************************************************************************
>    *      oset.h --                     Fixed format ordered set
> definitions.                            *
> diff -r -c -N postgresql-6.5Beta_Jun7/src/interfaces/libpq++/pgconnection.h
> postgresql-6.5_IRIX6.5/src/interfaces/libpq++/pgconnection.h
> *** postgresql-6.5Beta_Jun7/src/interfaces/libpq++/pgconnection.h       Sun May
> 23 00:01:46 1999
> --- postgresql-6.5_IRIX6.5/src/interfaces/libpq++/pgconnection.h        Mon Jun
> 7 16:17:40 1999
> ***************
> *** 27,32 ****
> --- 27,33 ----
>   #include "libpq-fe.h"
>   }
>
> + using namespace std;
>
>   // ****************************************************************
>   //
>
>
> --
> Mark Dalphin                          email: mdalphin@amgen.com
> Mail Stop: 29-2-A                     phone: +1-805-447-4951 (work)
> One Amgen Center Drive                       +1-805-375-0680 (home)
> Thousand Oaks, CA 91320                 fax: +1-805-499-9955 (work)
>
>


--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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