Thread: PostgreSQL supported platform report and a patch.
I am including a set of 4 small patches that enable PostgreSQL 7.3b3 to build successfully on OpenUnix 8.0. These same patches should also work for UnixWare 7.x. I will confirm that tomorrow (Nov 7, 2002). Here is an explanation of the patches: 1. An update of the FAQ_SCO file. 2. This patch removes a static declaration of a in-line function in src/backend/utils/sort/tuplesort.c 3. This patch to src/makefiles/Makefile.unixware, together with the patch to src/Makefile.global.in allows any addition library search directories (added with the configure --with-libraries option) to be added to the rpath option sent to the linker. The use of a different variable to pass the addition search paths was necessary to avoid a circular reference to LDFLAGS. 4. This patch creates the variable (trpath) used by the patch to Makefile.unixware. This patch would also be for other platforms that would have to add the additional library search paths to the rpath linker option. See Makefile.unixware for an example of how to do this. After applying these patches, PostgreSQL successfully compiled on OpenUnix 8 and it passed all the regression tests. ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 |
Attachment
I am fine with this because it only touches unixware-specific stuff, except the change to Tom's inline function: [static] inline Datum myFunctionCall2(FmgrInfo *flinfo, Datum arg1, Datum arg2) Tom will have to comment on that. --------------------------------------------------------------------------- Billy G. Allie wrote: -- Start of PGP signed section. > I am including a set of 4 small patches that enable PostgreSQL 7.3b3 to build > successfully on OpenUnix 8.0. These same patches should also work for UnixWare > 7.x. I will confirm that tomorrow (Nov 7, 2002). > > Here is an explanation of the patches: > > 1. An update of the FAQ_SCO file. > > 2. This patch removes a static declaration of a in-line function in > src/backend/utils/sort/tuplesort.c > > 3. This patch to src/makefiles/Makefile.unixware, together with the patch to > src/Makefile.global.in allows any addition library search directories (added > with the configure --with-libraries option) to be added to the rpath option > sent to the linker. The use of a different variable to pass the addition > search paths was necessary to avoid a circular reference to LDFLAGS. > > 4. This patch creates the variable (trpath) used by the patch to > Makefile.unixware. This patch would also be for other platforms that would > have to add the additional library search paths to the rpath linker option. > See Makefile.unixware for an example of how to do this. > > After applying these patches, PostgreSQL successfully compiled on OpenUnix 8 > and it passed all the regression tests. > Content-Description: ou8.patch.20021106 [ Attachment, skipping... ] > ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org > | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com > |-/-|----- | Dearborn, MI 48126| > |/ |LLIE | (313) 582-1540 | -- End of PGP section, PGP failed! -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am fine with this because it only touches unixware-specific stuff,
> except the change to Tom's inline function:
> [static] inline Datum
> myFunctionCall2(FmgrInfo *flinfo, Datum arg1, Datum arg2)
> Tom will have to comment on that.
That change would actively break some platforms (see C99 inline
specifications). Why is it necessary for SCO? We certainly have
plenty of other static inline functions ...
regards, tom lane
We already have success messages from Olivier Prenant for 7.3B4 on 8.0.0, and me for 7.1.3. I don't believe your changes are necessary. --On Wednesday, November 06, 2002 22:57:26 -0500 "Billy G. Allie" <Bill.Allie@mug.org> wrote: > I am including a set of 4 small patches that enable PostgreSQL 7.3b3 to > build successfully on OpenUnix 8.0. These same patches should also work > for UnixWare 7.x. I will confirm that tomorrow (Nov 7, 2002). > > Here is an explanation of the patches: > > 1. An update of the FAQ_SCO file. > > 2. This patch removes a static declaration of a in-line function in > src/backend/utils/sort/tuplesort.c > > 3. This patch to src/makefiles/Makefile.unixware, together with the patch > to src/Makefile.global.in allows any addition library search > directories (added with the configure --with-libraries option) to be > added to the rpath option sent to the linker. The use of a different > variable to pass the addition search paths was necessary to avoid a > circular reference to LDFLAGS. > > 4. This patch creates the variable (trpath) used by the patch to > Makefile.unixware. This patch would also be for other platforms that > would have to add the additional library search paths to the rpath > linker option. See Makefile.unixware for an example of how to do this. > > After applying these patches, PostgreSQL successfully compiled on > OpenUnix 8 and it passed all the regression tests. > -- Larry Rosenman, Sr. Network Engineer, Internet America, Inc. E-Mail: ler@airmail.net Phone: +1 214-861-2571, Fax: 214-861-2663 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201
"Billy G. Allie" <bga@mug.org> writes:
> Here is the error messages generated during the compile:
> cc -K pentium_pro,host,inline,loop_unroll -I../../../../src/include
> -I/usr/local/include -I/usr/local/ssl/include -c -o tuplesort.o tuplesort.c
> UX:acomp: ERROR: "tuplesort.c", line 1854: "inline" functions cannot use
> "static" identifier: myFunctionCall2
Uh, what version are you testing exactly? I thought we'd resolved that
as of a week or so back (certainly in 7.3b4).
regards, tom lane
Tom Lane wrote: > "Billy G. Allie" <bga@mug.org> writes: > > Here is the error messages generated during the compile: > > > cc -K pentium_pro,host,inline,loop_unroll -I../../../../src/include > > -I/usr/local/include -I/usr/local/ssl/include -c -o tuplesort.o tuplesort. > c > > UX:acomp: ERROR: "tuplesort.c", line 1854: "inline" functions cannot use > > "static" identifier: myFunctionCall2 > > Uh, what version are you testing exactly? I thought we'd resolved that > as of a week or so back (certainly in 7.3b4). It was 7.3b3. I've downloaded 7.3b5 and tested it. The problem with tuplesort.c has indeed been fixed. Bruce, ignore the patch to tuplesort.c that I sent in. The other three patches are still valid. Thanks. -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 |
Larry Rosenman <ler@lerctr.org> writes:
> I don't believe your changes are necessary.
The static-inline change was obsoleted by a recent fix, per discussion.
But the rpath changes seem possibly useful (or maybe my thoughts are
just colored by the fact that I'm currently trying to persuade OpenSSL
to build with a non-broken rpath setup on HPUX...) Do you have an
objection to the rpath part of Billy's patch?
regards, tom lane
That's true! But I had to export CFLAGS=-Xb to compile (this should be in port Makefile IMHO) Also, I think the Setting of LD_LIBRARY_PATH could be a win to. Although I doubt anyone would run uw whith at least LD_LIBRARY_PATH=/lib:/usr/local/lib, setting LD_LIBRARY_PATH and includes in the port makefile could ease the configure process as readline is not found if you don't add --with-includes ans --with-libs on configure command. Reagrds On Wed, 6 Nov 2002, Larry Rosenman wrote: > Date: Wed, 06 Nov 2002 23:27:31 -0600 > From: Larry Rosenman <ler@lerctr.org> > To: Billy G. Allie <Bill.Allie@mug.org>, pgsql-ports@postgresql.org > Cc: pgsql-hackers@postgresql.org > Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a > patch. > > We already have success messages from Olivier Prenant for 7.3B4 on 8.0.0, > and me for 7.1.3. > > I don't believe your changes are necessary. > > > > --On Wednesday, November 06, 2002 22:57:26 -0500 "Billy G. Allie" > <Bill.Allie@mug.org> wrote: > > > I am including a set of 4 small patches that enable PostgreSQL 7.3b3 to > > build successfully on OpenUnix 8.0. These same patches should also work > > for UnixWare 7.x. I will confirm that tomorrow (Nov 7, 2002). > > > > Here is an explanation of the patches: > > > > 1. An update of the FAQ_SCO file. > > > > 2. This patch removes a static declaration of a in-line function in > > src/backend/utils/sort/tuplesort.c > > > > 3. This patch to src/makefiles/Makefile.unixware, together with the patch > > to src/Makefile.global.in allows any addition library search > > directories (added with the configure --with-libraries option) to be > > added to the rpath option sent to the linker. The use of a different > > variable to pass the addition search paths was necessary to avoid a > > circular reference to LDFLAGS. > > > > 4. This patch creates the variable (trpath) used by the patch to > > Makefile.unixware. This patch would also be for other platforms that > > would have to add the additional library search paths to the rpath > > linker option. See Makefile.unixware for an example of how to do this. > > > > After applying these patches, PostgreSQL successfully compiled on > > OpenUnix 8 and it passed all the regression tests. > > > > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr ------------------------------------------------------------------------------ Make your life a dream, make your dream a reality. (St Exupery)
--On Thursday, November 07, 2002 01:17:55 -0500 "Billy G. Allie" <bga@mug.org> wrote: > Larry Rosenman wrote: >> We already have success messages from Olivier Prenant for 7.3B4 on >> 8.0.0, and me for 7.1.3. >> >> I don't believe your changes are necessary. >> > > Was that using gcc or the native compiler? Native. > Was it in linux kernel personality mode or OpenUNIX mode. > Native. > I was compiling using the native (UDK) compiler. and it failed in > tuplesort.c. It was also unable to file the readline shared libraries > without the changes to the makefiles or setting LD_RUN_PATH (which is a > pain and is depreciated in OpenUNIX 8 and UnixWare 7). Tom fixed the tuplesort.c issue with some help from the Caldera/SCO Compiler team (I'm on the 7.1.3 BETA). My system has always found the readline stuff (I use the skunkware readline). It hasn't been an issue on my system. > > -- > ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org >| /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com >| -/-|----- | Dearborn, MI 48126| >| / |LLIE | (313) 582-1540 | > > -- Larry Rosenman, Sr. Network Engineer, Internet America, Inc. E-Mail: ler@airmail.net Phone: +1 214-861-2571, Fax: 214-861-2663 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201
--On Thursday, November 07, 2002 02:42:47 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Larry Rosenman <ler@lerctr.org> writes: >> I don't believe your changes are necessary. > > The static-inline change was obsoleted by a recent fix, per discussion. > But the rpath changes seem possibly useful (or maybe my thoughts are > just colored by the fact that I'm currently trying to persuade OpenSSL > to build with a non-broken rpath setup on HPUX...) Do you have an > objection to the rpath part of Billy's patch? Not necessarily. I was just concerned about the tuplesort one, and the fact that mine builds and passes without the changes. > > regards, tom lane -- Larry Rosenman, Sr. Network Engineer, Internet America, Inc. E-Mail: ler@airmail.net Phone: +1 214-861-2571, Fax: 214-861-2663 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201
--On Thursday, November 07, 2002 13:32:18 +0100 Olivier PRENANT <ohp@pyrenet.fr> wrote: > That's true! > > But I had to export CFLAGS=-Xb to compile (this should be in port Makefile > IMHO) Tom fixed that with a later tuplesort.c fix (per a discussion with the Caldera/SCO compiler guys). > Also, I think the Setting of LD_LIBRARY_PATH could be a win to. Although I > doubt anyone would run uw whith at least > LD_LIBRARY_PATH=/lib:/usr/local/lib, setting LD_LIBRARY_PATH and includes > in the port makefile could ease the configure process as readline is not > found if you don't add --with-includes ans --with-libs on configure > command. Not a problem here. (the change that is). > > Reagrds > On Wed, 6 Nov 2002, Larry Rosenman wrote: > >> Date: Wed, 06 Nov 2002 23:27:31 -0600 >> From: Larry Rosenman <ler@lerctr.org> >> To: Billy G. Allie <Bill.Allie@mug.org>, pgsql-ports@postgresql.org >> Cc: pgsql-hackers@postgresql.org >> Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a >> patch. >> >> We already have success messages from Olivier Prenant for 7.3B4 on >> 8.0.0, and me for 7.1.3. >> >> I don't believe your changes are necessary. >> >> >> >> --On Wednesday, November 06, 2002 22:57:26 -0500 "Billy G. Allie" >> <Bill.Allie@mug.org> wrote: >> >> > I am including a set of 4 small patches that enable PostgreSQL 7.3b3 to >> > build successfully on OpenUnix 8.0. These same patches should also >> > work for UnixWare 7.x. I will confirm that tomorrow (Nov 7, 2002). >> > >> > Here is an explanation of the patches: >> > >> > 1. An update of the FAQ_SCO file. >> > >> > 2. This patch removes a static declaration of a in-line function in >> > src/backend/utils/sort/tuplesort.c >> > >> > 3. This patch to src/makefiles/Makefile.unixware, together with the >> > patch to src/Makefile.global.in allows any addition library search >> > directories (added with the configure --with-libraries option) to be >> > added to the rpath option sent to the linker. The use of a >> > different variable to pass the addition search paths was necessary >> > to avoid a circular reference to LDFLAGS. >> > >> > 4. This patch creates the variable (trpath) used by the patch to >> > Makefile.unixware. This patch would also be for other platforms >> > that would have to add the additional library search paths to >> > the rpath linker option. See Makefile.unixware for an example of >> > how to do this. >> > >> > After applying these patches, PostgreSQL successfully compiled on >> > OpenUnix 8 and it passed all the regression tests. >> > >> >> >> >> > > -- > Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) > Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) > 31190 AUTERIVE +33-6-07-63-80-64 (GSM) > FRANCE Email: ohp@pyrenet.fr > ------------------------------------------------------------------------- > ----- Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman, Sr. Network Engineer, Internet America, Inc. E-Mail: ler@airmail.net Phone: +1 214-861-2571, Fax: 214-861-2663 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201
On Thu, 7 Nov 2002, Larry Rosenman wrote: > Date: Thu, 07 Nov 2002 06:41:02 -0600 > From: Larry Rosenman <ler@lerctr.org> > To: ohp@pyrenet.fr > Cc: Billy G. Allie <Bill.Allie@mug.org>, pgsql-ports@postgresql.org, > pgsql-hackers@postgresql.org > Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a > > > > --On Thursday, November 07, 2002 13:32:18 +0100 Olivier PRENANT > <ohp@pyrenet.fr> wrote: > > > That's true! > > > > But I had to export CFLAGS=-Xb to compile (this should be in port Makefile > > IMHO) > Tom fixed that with a later tuplesort.c fix (per a discussion with the > Caldera/SCO > compiler guys). Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the compiler... > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr ------------------------------------------------------------------------------ Make your life a dream, make your dream a reality. (St Exupery)
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I am fine with this because it only touches unixware-specific stuff,
> > except the change to Tom's inline function:
> > [static] inline Datum
> > myFunctionCall2(FmgrInfo *flinfo, Datum arg1, Datum arg2)
> > Tom will have to comment on that.
>
> That change would actively break some platforms (see C99 inline
> specifications). Why is it necessary for SCO? We certainly have
> plenty of other static inline functions ...
>
> regards, tom lane
Here is the error messages generated during the compile:
cc -K pentium_pro,host,inline,loop_unroll -I../../../../src/include
-I/usr/local/include -I/usr/local/ssl/include -c -o tuplesort.o tuplesort.c
UX:acomp: ERROR: "tuplesort.c", line 1854: "inline" functions cannot use
"static" identifier: myFunctionCall2
UX:acomp: ERROR: "tuplesort.c", line 1856: "inline" functions cannot use
"static" identifier: myFunctionCall2
UX:acomp: ERROR: "tuplesort.c", line 1870: "inline" functions cannot use
"static" identifier: myFunctionCall2
UX:acomp: ERROR: "tuplesort.c", line 1872: "inline" functions cannot use
"static" identifier: myFunctionCall2
UX:acomp: ERROR: "tuplesort.c", line 1885: "inline" functions cannot use
"static" identifier: myFunctionCall2
UX:acomp: ERROR: "tuplesort.c", line 1897: "inline" functions cannot use
"static" identifier: myFunctionCall2
gmake[4]: *** [tuplesort.o] Error 1
The problem only occurs in tuplesort.c. It does not occur in pg_lzcompress.c
or aset.c, which are the only other source files that contain static inline
function definitions that get compiled. The rest are IF DEFed out.
I think the problem is that myFunctionCall2 is called by a non-static inline
function, ApplySortFunction. If I make ApplySortFunction static, it compiles
(but break the link phase). If I remove the inline from ApplySortFunction, it
compiles and builds. In order for tuplesort.c to compile on OpenUNIX the code
must be changed to either:
1. Remove the static modifier from myFuntionCall2
or
2. Remove the inline from ApplySortFunction
or
3. Wrap the static modifier for myFunctionCall2 with an IF DEF so it's not
there when USE_UNIVEL_CC is defined.
I think that option 2 is the best choice, but it's your call.
--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com
|-/-|----- | Dearborn, MI 48126|
|/ |LLIE | (313) 582-1540 |
Larry Rosenman wrote: > We already have success messages from Olivier Prenant for 7.3B4 on 8.0.0, > and me for 7.1.3. > > I don't believe your changes are necessary. > Was that using gcc or the native compiler? Was it in linux kernel personality mode or OpenUNIX mode. I was compiling using the native (UDK) compiler. and it failed in tuplesort.c. It was also unable to file the readline shared libraries without the changes to the makefiles or setting LD_RUN_PATH (whichis a pain and is depreciated in OpenUNIX 8 and UnixWare 7). -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 |
Tom Lane wrote: > "Billy G. Allie" <bga@mug.org> writes: > > Here is the error messages generated during the compile: > > > cc -K pentium_pro,host,inline,loop_unroll -I../../../../src/include > > -I/usr/local/include -I/usr/local/ssl/include -c -o tuplesort.o tuplesort. > c > > UX:acomp: ERROR: "tuplesort.c", line 1854: "inline" functions cannot use > > "static" identifier: myFunctionCall2 > > Uh, what version are you testing exactly? I thought we'd resolved that > as of a week or so back (certainly in 7.3b4). It was 7.3b3. I've just downloaded 7.3b5 and will re-test. If that's the case then ignore the patch to tuplesort.c The rest of the patches are still valid though. -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 |
--On Thursday, November 07, 2002 14:23:43 +0100 Olivier PRENANT <ohp@pyrenet.fr> wrote: > On Thu, 7 Nov 2002, Larry Rosenman wrote: > >> Date: Thu, 07 Nov 2002 06:41:02 -0600 >> From: Larry Rosenman <ler@lerctr.org> >> To: ohp@pyrenet.fr >> Cc: Billy G. Allie <Bill.Allie@mug.org>, pgsql-ports@postgresql.org, >> pgsql-hackers@postgresql.org >> Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a >> >> >> >> --On Thursday, November 07, 2002 13:32:18 +0100 Olivier PRENANT >> <ohp@pyrenet.fr> wrote: >> >> > That's true! >> > >> > But I had to export CFLAGS=-Xb to compile (this should be in port >> > Makefile IMHO) >> Tom fixed that with a later tuplesort.c fix (per a discussion with the >> Caldera/SCO >> compiler guys). > Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the > compiler... >> Didn't for me.... :-( Wierd. > > -- > Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) > Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) > 31190 AUTERIVE +33-6-07-63-80-64 (GSM) > FRANCE Email: ohp@pyrenet.fr > ------------------------------------------------------------------------- > ----- Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Olivier PRENANT <ohp@pyrenet.fr> writes:
> Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the
> compiler...
It won't get better if you don't show any details...
regards, tom lane
On Thu, 7 Nov 2002, Larry Rosenman wrote: > Date: Thu, 07 Nov 2002 08:41:58 -0600 > From: Larry Rosenman <ler@lerctr.org> > To: ohp@pyrenet.fr > Cc: Billy G. Allie <Bill.Allie@mug.org>, pgsql-ports@postgresql.org, > pgsql-hackers@postgresql.org > Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a > > > > >> Tom fixed that with a later tuplesort.c fix (per a discussion with the > >> Caldera/SCO > >> compiler guys). > > Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the > > compiler... > >> > Didn't for me.... :-( > > Wierd. BTW, this is on 7.1.1 not (yet) on 8.0.0 I'll let you know hopefully today. (How did you get 713 when it's due for december?) Can I have a copy? > > > > > > -- > > Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) > > Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) > > 31190 AUTERIVE +33-6-07-63-80-64 (GSM) > > FRANCE Email: ohp@pyrenet.fr > > ------------------------------------------------------------------------- > > ----- Make your life a dream, make your dream a reality. (St Exupery) > > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr ------------------------------------------------------------------------------ Make your life a dream, make your dream a reality. (St Exupery)
--On Thursday, November 07, 2002 15:44:37 +0100 Olivier PRENANT <ohp@pyrenet.fr> wrote: > On Thu, 7 Nov 2002, Larry Rosenman wrote: > >> Date: Thu, 07 Nov 2002 08:41:58 -0600 >> From: Larry Rosenman <ler@lerctr.org> >> To: ohp@pyrenet.fr >> Cc: Billy G. Allie <Bill.Allie@mug.org>, pgsql-ports@postgresql.org, >> pgsql-hackers@postgresql.org >> Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a >> >> >> >> >> Tom fixed that with a later tuplesort.c fix (per a discussion with the >> >> Caldera/SCO >> >> compiler guys). >> > Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs >> > the compiler... >> >> >> Didn't for me.... :-( >> >> Wierd. > BTW, this is on 7.1.1 not (yet) on 8.0.0 > I'll let you know hopefully today. > > (How did you get 713 when it's due for december?) Can I have a copy? I'm on the Beta. No, I can't give it to you. You might want to sign up on http://www.caldera.com/beta/ to get in on the next one. >> >> >> > >> > -- >> > Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) >> > Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) >> > 31190 AUTERIVE +33-6-07-63-80-64 (GSM) >> > FRANCE Email: ohp@pyrenet.fr >> > ---------------------------------------------------------------------- >> > --- ----- Make your life a dream, make your dream a reality. (St >> > Exupery) >> >> >> >> > > -- > Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) > Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) > 31190 AUTERIVE +33-6-07-63-80-64 (GSM) > FRANCE Email: ohp@pyrenet.fr > ------------------------------------------------------------------------- > ----- Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
On Thu, 7 Nov 2002, Tom Lane wrote: > Date: Thu, 07 Nov 2002 10:21:25 -0500 > From: Tom Lane <tgl@sss.pgh.pa.us> > To: ohp@pyrenet.fr > Cc: Larry Rosenman <ler@lerctr.org>, Billy G. Allie <Bill.Allie@mug.org>, > pgsql-ports@postgresql.org, pgsql-hackers@postgresql.org > Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a > > Olivier PRENANT <ohp@pyrenet.fr> writes: > > Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the > > compiler... > > It won't get better if you don't show any details... Ok... (sorry) this is on UW 711 WITHOUT CFLAGS=-Xb: Script started on Thu Nov 7 16:57:05 2002 $ cd postgresql*5 $ make Using GNU make found at /usr/local/bin/gmake /usr/local/bin/gmake -C doc all gmake[1]: Entering directory `/home/postgres/postgresql-7.3b5/doc' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/postgres/postgresql-7.3b5/doc' /usr/local/bin/gmake -C src all gmake[1]: Entering directory `/home/postgres/postgresql-7.3b5/src' /usr/local/bin/gmake -C port all gmake[2]: Entering directory `/home/postgres/postgresql-7.3b5/src/port' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/home/postgres/postgresql-7.3b5/src/port' /usr/local/bin/gmake -C backend all gmake[2]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend' /usr/local/bin/gmake -C ../../src/port all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/port' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/port' /usr/local/bin/gmake -C access all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access' /usr/local/bin/gmake -C common SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/common' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/common' /usr/local/bin/gmake -C gist SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/gist' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/gist' /usr/local/bin/gmake -C hash SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/hash' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/hash' /usr/local/bin/gmake -C heap SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/heap' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/heap' /usr/local/bin/gmake -C index SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/index' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/index' /usr/local/bin/gmake -C nbtree SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/nbtree' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/nbtree' /usr/local/bin/gmake -C rtree SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/rtree' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/rtree' /usr/local/bin/gmake -C transam SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/transam' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/transam' gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access' /usr/local/bin/gmake -C bootstrap all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/bootstrap' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/bootstrap' /usr/local/bin/gmake -C catalog all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/catalog' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/catalog' /usr/local/bin/gmake -C parser all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/parser' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/parser' /usr/local/bin/gmake -C commands all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/commands' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/commands' /usr/local/bin/gmake -C executor all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/executor' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/executor' /usr/local/bin/gmake -C lib all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/lib' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/lib' /usr/local/bin/gmake -C libpq all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/libpq' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/libpq' /usr/local/bin/gmake -C main all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/main' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/main' /usr/local/bin/gmake -C nodes all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/nodes' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/nodes' /usr/local/bin/gmake -C optimizer all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer' /usr/local/bin/gmake -C geqo SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer/geqo' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer/geqo' /usr/local/bin/gmake -C path SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer/path' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer/path' /usr/local/bin/gmake -C plan SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer/plan' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer/plan' /usr/local/bin/gmake -C prep SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer/prep' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer/prep' /usr/local/bin/gmake -C util SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer/util' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer/util' gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/optimizer' /usr/local/bin/gmake -C port all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/port' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/port' /usr/local/bin/gmake -C postmaster all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/postmaster' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/postmaster' /usr/local/bin/gmake -C regex all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/regex' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/regex' /usr/local/bin/gmake -C rewrite all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/rewrite' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/rewrite' /usr/local/bin/gmake -C storage all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/storage' /usr/local/bin/gmake -C buffer SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/storage/buffer' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/storage/buffer' /usr/local/bin/gmake -C file SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/storage/file' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/storage/file' /usr/local/bin/gmake -C freespace SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/storage/freespace' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/storage/freespace' /usr/local/bin/gmake -C ipc SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/storage/ipc' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/storage/ipc' /usr/local/bin/gmake -C large_object SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/storage/large_object' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/storage/large_object' /usr/local/bin/gmake -C lmgr SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/storage/lmgr' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/storage/lmgr' /usr/local/bin/gmake -C page SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/storage/page' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/storage/page' /usr/local/bin/gmake -C smgr SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/storage/smgr' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/storage/smgr' gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/storage' /usr/local/bin/gmake -C tcop all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/tcop' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/tcop' /usr/local/bin/gmake -C utils all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/utils' /usr/local/bin/gmake -C adt SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/utils/adt' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/utils/adt' /usr/local/bin/gmake -C cache SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/utils/cache' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/utils/cache' /usr/local/bin/gmake -C error SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/utils/error' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/utils/error' /usr/local/bin/gmake -C fmgr SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/utils/fmgr' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/utils/fmgr' /usr/local/bin/gmake -C hash SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/utils/hash' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/utils/hash' /usr/local/bin/gmake -C init SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/utils/init' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/utils/init' /usr/local/bin/gmake -C misc SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/utils/misc' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/utils/misc' /usr/local/bin/gmake -C mmgr SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/utils/mmgr' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/utils/mmgr' /usr/local/bin/gmake -C sort SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/utils/sort' cc -O -K inline -I../../../../src/include -I/usr/local/include -c tuplesort.c -o tuplesort.o UX:acomp: ERREUR: "tuplesort.c", ligne 1854: "inline" functions cannot use "static" identifier: myFunctionCall2 UX:acomp: ERREUR: "tuplesort.c", ligne 1856: "inline" functions cannot use "static" identifier: myFunctionCall2 UX:acomp: ERREUR: "tuplesort.c", ligne 1870: "inline" functions cannot use "static" identifier: myFunctionCall2 UX:acomp: ERREUR: "tuplesort.c", ligne 1872: "inline" functions cannot use "static" identifier: myFunctionCall2 UX:acomp: ERREUR: "tuplesort.c", ligne 1885: "inline" functions cannot use "static" identifier: myFunctionCall2 UX:acomp: ERREUR: "tuplesort.c", ligne 1897: "inline" functions cannot use "static" identifier: myFunctionCall2 gmake[4]: *** [tuplesort.o] Error 1 gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/utils/sort' gmake[3]: *** [sort-recursive] Error 2 gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/utils' gmake[2]: *** [utils-recursive] Error 2 gmake[2]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/postgres/postgresql-7.3b5/src' gmake: *** [all] Error 2 *** Code d'erreur 2 (bu21) UX:make: ERREUR: erreur irrémédiable. script done on Thu Nov 7 16:57:29 2002 It works OK with -Xb... Regards > > regards, tom lane > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr ------------------------------------------------------------------------------ Make your life a dream, make your dream a reality. (St Exupery)
Bruce Momjian writes: > I am fine with this because it only touches unixware-specific stuff, This is an entirely new feature, so it's inappropriate to do now. And if we do it, we should do it for all platforms. -- Peter Eisentraut peter_e@gmx.net
Larry Rosenman wrote: > Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Larry Rosenman <ler@lerctr.org> writes: > >> I don't believe your changes are necessary. > > > > The static-inline change was obsoleted by a recent fix, per discussion. > > But the rpath changes seem possibly useful (or maybe my thoughts are > > just colored by the fact that I'm currently trying to persuade OpenSSL > > to build with a non-broken rpath setup on HPUX...) Do you have an > > objection to the rpath part of Billy's patch? > > Not necessarily. I was just concerned about the tuplesort one, and the fact > that mine builds and passes without the changes. Larry, You probably have /usr/local/lib LD_LIBRARY_PATH. On my system LD_LIBRARY_PATH defaults to /usr/X/lib:/lib and LD_RUN_PATH are not set, and I prefer it that way. The rpath related changes allow me to specify the additional library search paths by using the configure --with-libraries option and have those paths placed into the executable so that the executables can run without having to the default setting of LD_LIBRARY_PATH. After reading the discussions, I can think of another enhancement to the rpath changes: have the contents of LD_LIBRARY_PATH added to the -R (or -rpath) option inside the port specific makefile. That way, if you add the additional search paths to LD_LIBRARY_PATH you won't have to use the --with-libraries and the executable(s) will have the runtime search paths in them so they will execute without having to change the default LD_LIBRARY_PATH setting. -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 |
Billy, so your rpath changes are for handling customization you made to your OS. Sounds like a feature addition to me, which will go into 7.4 only. --------------------------------------------------------------------------- Billy G. Allie wrote: -- Start of PGP signed section. > Larry Rosenman wrote: > > Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > Larry Rosenman <ler@lerctr.org> writes: > > >> I don't believe your changes are necessary. > > > > > > The static-inline change was obsoleted by a recent fix, per discussion. > > > But the rpath changes seem possibly useful (or maybe my thoughts are > > > just colored by the fact that I'm currently trying to persuade OpenSSL > > > to build with a non-broken rpath setup on HPUX...) Do you have an > > > objection to the rpath part of Billy's patch? > > > > Not necessarily. I was just concerned about the tuplesort one, and the fact > > that mine builds and passes without the changes. > > Larry, > > You probably have /usr/local/lib LD_LIBRARY_PATH. On my system > LD_LIBRARY_PATH defaults to /usr/X/lib:/lib and LD_RUN_PATH are not set, and I > prefer it that way. The rpath related changes allow me to specify the > additional library search paths by using the configure --with-libraries option > and have those paths placed into the executable so that the executables can > run without having to the default setting of LD_LIBRARY_PATH. > > After reading the discussions, I can think of another enhancement to the rpath > changes: have the contents of LD_LIBRARY_PATH added to the -R (or -rpath) > option inside the port specific makefile. That way, if you add the additional > search paths to LD_LIBRARY_PATH you won't have to use the --with-libraries and > the executable(s) will have the runtime search paths in them so they will > execute without having to change the default LD_LIBRARY_PATH setting. > -- > ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org > | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com > |-/-|----- | Dearborn, MI 48126| > |/ |LLIE | (313) 582-1540 | > > -- End of PGP section, PGP failed! -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
This has been saved for the 7.4 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
I will not apply the _inline_ part.
---------------------------------------------------------------------------
Billy G. Allie wrote:
-- Start of PGP signed section.
> I am including a set of 4 small patches that enable PostgreSQL 7.3b3 to build
> successfully on OpenUnix 8.0. These same patches should also work for UnixWare
> 7.x. I will confirm that tomorrow (Nov 7, 2002).
>
> Here is an explanation of the patches:
>
> 1. An update of the FAQ_SCO file.
>
> 2. This patch removes a static declaration of a in-line function in
> src/backend/utils/sort/tuplesort.c
>
> 3. This patch to src/makefiles/Makefile.unixware, together with the patch to
> src/Makefile.global.in allows any addition library search directories (added
> with the configure --with-libraries option) to be added to the rpath option
> sent to the linker. The use of a different variable to pass the addition
> search paths was necessary to avoid a circular reference to LDFLAGS.
>
> 4. This patch creates the variable (trpath) used by the patch to
> Makefile.unixware. This patch would also be for other platforms that would
> have to add the additional library search paths to the rpath linker option.
> See Makefile.unixware for an example of how to do this.
>
> After applying these patches, PostgreSQL successfully compiled on OpenUnix 8
> and it passed all the regression tests.
>
Content-Description: ou8.patch.20021106
[ Attachment, skipping... ]
> ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
> | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com
> |-/-|----- | Dearborn, MI 48126|
> |/ |LLIE | (313) 582-1540 |
-- End of PGP section, PGP failed!
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073