PostgreSQL supported platform report and a patch.

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

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 |

"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

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 (which is 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 |

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)

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

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

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, 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)

It looks like you do **NOT** have B4 or B5....

LER

--On Thursday, November 07, 2002 17:00:21 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

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)

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

*WHAT??**

this directory has hust been created by de-taring postgresql-7.3b5.tar.gz
from my own mirror dated nov 6 20:04...

On Thu, 7 Nov 2002, Larry Rosenman wrote:

Date: Thu, 07 Nov 2002 10:07:37 -0600
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr, Tom Lane <tgl@sss.pgh.pa.us>
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

It looks like you do **NOT** have B4 or B5....

LER

--On Thursday, November 07, 2002 17:00:21 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

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)

--
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 <ohp@pyrenet.fr> writes:

*WHAT??**
this directory has hust been created by de-taring postgresql-7.3b5.tar.gz
from my own mirror dated nov 6 20:04...

Well, there's something darn weird here. Is
src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838,
do you see
inline int32
ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
or
static inline int32
inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,

regards, tom lane

I see the latter in both b4 and b5!

I've just relaunched my mirroring procedure and it did'nt pick another b4
or b5!

What happens??

Regards,
On Thu, 7 Nov 2002, Tom Lane wrote:

Date: Thu, 07 Nov 2002 11:26:42 -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:

*WHAT??**
this directory has hust been created by de-taring postgresql-7.3b5.tar.gz
from my own mirror dated nov 6 20:04...

Well, there's something darn weird here. Is
src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838,
do you see
inline int32
ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
or
static inline int32
inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,

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)

It **LOOKS** right. I'm about to double check it on 7.1.3.

Olivier, is this the 7.1.1b FS Compiler?

I wonder if a bug fix made it in...

Wierd.

--On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

I see the latter in both b4 and b5!

I've just relaunched my mirroring procedure and it did'nt pick another b4
or b5!

What happens??

Regards,
On Thu, 7 Nov 2002, Tom Lane wrote:

Date: Thu, 07 Nov 2002 11:26:42 -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:

*WHAT??**
this directory has hust been created by de-taring
postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04...

Well, there's something darn weird here. Is
src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838,
do you see
inline int32
ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
or
static inline int32
inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,

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)

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

What's FS, it(s the 7.1.1b compiler yes.

I don't mind having CFLAGS=-Xb though, done it for php already...
By everyone says this should go off so..

Regards
On Thu, 7 Nov 2002, Larry Rosenman wrote:

Date: Thu, 07 Nov 2002 10:37:36 -0600
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr, Tom Lane <tgl@sss.pgh.pa.us>
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

It **LOOKS** right. I'm about to double check it on 7.1.3.

Olivier, is this the 7.1.1b FS Compiler?

I wonder if a bug fix made it in...

Wierd.

--On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

I see the latter in both b4 and b5!

I've just relaunched my mirroring procedure and it did'nt pick another b4
or b5!

What happens??

Regards,
On Thu, 7 Nov 2002, Tom Lane wrote:

Date: Thu, 07 Nov 2002 11:26:42 -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:

*WHAT??**
this directory has hust been created by de-taring
postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04...

Well, there's something darn weird here. Is
src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838,
do you see
inline int32
ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
or
static inline int32
inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,

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)

--
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)

FS== Feature Supplement.

I've got a compile running with the 7.3b5 tarball on my 7.1.3 system (with
the newer
compiler).

We'll see. :-)

--On Thursday, November 07, 2002 17:40:24 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

What's FS, it(s the 7.1.1b compiler yes.

I don't mind having CFLAGS=-Xb though, done it for php already...
By everyone says this should go off so..

Regards
On Thu, 7 Nov 2002, Larry Rosenman wrote:

Date: Thu, 07 Nov 2002 10:37:36 -0600
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr, Tom Lane <tgl@sss.pgh.pa.us>
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

It **LOOKS** right. I'm about to double check it on 7.1.3.

Olivier, is this the 7.1.1b FS Compiler?

I wonder if a bug fix made it in...

Wierd.

--On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

I see the latter in both b4 and b5!

I've just relaunched my mirroring procedure and it did'nt pick another
b4 or b5!

What happens??

Regards,
On Thu, 7 Nov 2002, Tom Lane wrote:

Date: Thu, 07 Nov 2002 11:26:42 -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:

*WHAT??**
this directory has hust been created by de-taring
postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04...

Well, there's something darn weird here. Is
src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line
1838, do you see
inline int32
ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
or
static inline int32
inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind
kind,

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)

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

cc -O -g -I../../../../src/include -I/usr/local/include -c -o tuplesort.o
tuplesort.c
UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled

It still passes here. I really wonder if they fixed something in the 4.1
compiler. IIRC
the 7.1.1b compiler is 4.0.

Truly wierd.

LER

--On Thursday, November 07, 2002 17:40:24 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

What's FS, it(s the 7.1.1b compiler yes.

I don't mind having CFLAGS=-Xb though, done it for php already...
By everyone says this should go off so..

Regards
On Thu, 7 Nov 2002, Larry Rosenman wrote:

Date: Thu, 07 Nov 2002 10:37:36 -0600
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr, Tom Lane <tgl@sss.pgh.pa.us>
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

It **LOOKS** right. I'm about to double check it on 7.1.3.

Olivier, is this the 7.1.1b FS Compiler?

I wonder if a bug fix made it in...

Wierd.

--On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

I see the latter in both b4 and b5!

I've just relaunched my mirroring procedure and it did'nt pick another
b4 or b5!

What happens??

Regards,
On Thu, 7 Nov 2002, Tom Lane wrote:

Date: Thu, 07 Nov 2002 11:26:42 -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:

*WHAT??**
this directory has hust been created by de-taring
postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04...

Well, there's something darn weird here. Is
src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line
1838, do you see
inline int32
ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
or
static inline int32
inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind
kind,

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)

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

Haha!!!

It passes (b4) on 800 and not on uw 711..

Larry, should I install 800 SDK on 711?

On Thu, 7 Nov 2002, Larry Rosenman wrote:

Date: Thu, 07 Nov 2002 10:45:13 -0600
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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

cc -O -g -I../../../../src/include -I/usr/local/include -c -o tuplesort.o
tuplesort.c
UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled

It still passes here. I really wonder if they fixed something in the 4.1
compiler. IIRC
the 7.1.1b compiler is 4.0.

Truly wierd.

LER

--On Thursday, November 07, 2002 17:40:24 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

What's FS, it(s the 7.1.1b compiler yes.

I don't mind having CFLAGS=-Xb though, done it for php already...
By everyone says this should go off so..

Regards
On Thu, 7 Nov 2002, Larry Rosenman wrote:

Date: Thu, 07 Nov 2002 10:37:36 -0600
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr, Tom Lane <tgl@sss.pgh.pa.us>
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

It **LOOKS** right. I'm about to double check it on 7.1.3.

Olivier, is this the 7.1.1b FS Compiler?

I wonder if a bug fix made it in...

Wierd.

--On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

I see the latter in both b4 and b5!

I've just relaunched my mirroring procedure and it did'nt pick another
b4 or b5!

What happens??

Regards,
On Thu, 7 Nov 2002, Tom Lane wrote:

Date: Thu, 07 Nov 2002 11:26:42 -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:

*WHAT??**
this directory has hust been created by de-taring
postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04...

Well, there's something darn weird here. Is
src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line
1838, do you see
inline int32
ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
or
static inline int32
inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind
kind,

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)

--
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 18:02:51 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

Haha!!!

It passes (b4) on 800 and not on uw 711..

Larry, should I install 800 SDK on 711?

Yes.

On Thu, 7 Nov 2002, Larry Rosenman wrote:

Date: Thu, 07 Nov 2002 10:45:13 -0600
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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

cc -O -g -I../../../../src/include -I/usr/local/include -c -o
tuplesort.o tuplesort.c
UX:cc: WARNING: debugging and optimization mutually exclusive; -O
disabled

It still passes here. I really wonder if they fixed something in the
4.1 compiler. IIRC
the 7.1.1b compiler is 4.0.

Truly wierd.

LER

--On Thursday, November 07, 2002 17:40:24 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

What's FS, it(s the 7.1.1b compiler yes.

I don't mind having CFLAGS=-Xb though, done it for php already...
By everyone says this should go off so..

Regards
On Thu, 7 Nov 2002, Larry Rosenman wrote:

Date: Thu, 07 Nov 2002 10:37:36 -0600
From: Larry Rosenman <ler@lerctr.org>
To: ohp@pyrenet.fr, Tom Lane <tgl@sss.pgh.pa.us>
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

It **LOOKS** right. I'm about to double check it on 7.1.3.

Olivier, is this the 7.1.1b FS Compiler?

I wonder if a bug fix made it in...

Wierd.

--On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT
<ohp@pyrenet.fr> wrote:

I see the latter in both b4 and b5!

I've just relaunched my mirroring procedure and it did'nt pick
another b4 or b5!

What happens??

Regards,
On Thu, 7 Nov 2002, Tom Lane wrote:

Date: Thu, 07 Nov 2002 11:26:42 -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:

*WHAT??**
this directory has hust been created by de-taring
postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04...

Well, there's something darn weird here. Is
src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line
1838, do you see
inline int32
ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
or
static inline int32
inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind
kind,

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)

--
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)

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
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 Thursday, November 07, 2002 22:21:56 +0100 Peter Eisentraut
<peter_e@gmx.net> wrote:

Olivier PRENANT writes:

I don't mind having CFLAGS=-Xb though, done it for php already...
By everyone says this should go off so..

The idea of the platform testing is not to determine whether you can
compile PostgreSQL after performing a secret dance. If it doesn't compile
with the default options, please don't report it as supported.

It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3. Apparently a
compiler
fix between the 7.1.1b FS and 7.1.2.

The -Xb switch is NOT a secret dance. It's needed for LOTS of open source
stuff.

See the discussion from the Caldera folks last week.

Tom's fix fixed the defaults for 7.1.2+

--
Peter Eisentraut peter_e@gmx.net

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

I don't mind having CFLAGS=-Xb though, done it for php already...
By everyone says this should go off so..

The idea of the platform testing is not to determine whether you can
compile PostgreSQL after performing a secret dance. If it doesn't compile
with the default options, please don't report it as supported.

--
Peter Eisentraut peter_e@gmx.net

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 <ler@lerctr.org> writes:

It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3. Apparently a
compiler
fix between the 7.1.1b FS and 7.1.2.

Well, this is what the REMARKS column is for in the supported-platform
list. Seems we need a comment like "for older compiler versions, you
may need to add -Xb to CFLAGS". Can anyone provide a short and accurate
description of when to do this?

regards, tom lane

For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare
7.1.2), Including
the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS or the
CC environment
variable.

--On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane
<tgl@sss.pgh.pa.us> wrote:

Larry Rosenman <ler@lerctr.org> writes:

It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3.
Apparently a compiler
fix between the 7.1.1b FS and 7.1.2.

Well, this is what the REMARKS column is for in the supported-platform
list. Seems we need a comment like "for older compiler versions, you
may need to add -Xb to CFLAGS". Can anyone provide a short and accurate
description of when to do this?

regards, tom lane

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

We do point to the FAQ_SCO file for specifics. Would you send a diff
for that file?

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

Larry Rosenman wrote:

For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare
7.1.2), Including
the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS or the
CC environment
variable.

--On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane
<tgl@sss.pgh.pa.us> wrote:

Larry Rosenman <ler@lerctr.org> writes:

It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3.
Apparently a compiler
fix between the 7.1.1b FS and 7.1.2.

Well, this is what the REMARKS column is for in the supported-platform
list. Seems we need a comment like "for older compiler versions, you
may need to add -Xb to CFLAGS". Can anyone provide a short and accurate
description of when to do this?

regards, tom lane

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

With or withou Billie's update(s)?

(I haven't looked at them)....

LER

--On Thursday, November 07, 2002 17:08:04 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

We do point to the FAQ_SCO file for specifics. Would you send a diff
for that file?

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

Larry Rosenman wrote:

For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare
7.1.2), Including
the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS or
the CC environment
variable.

--On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane
<tgl@sss.pgh.pa.us> wrote:

Larry Rosenman <ler@lerctr.org> writes:

It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3.
Apparently a compiler
fix between the 7.1.1b FS and 7.1.2.

Well, this is what the REMARKS column is for in the supported-platform
list. Seems we need a comment like "for older compiler versions, you
may need to add -Xb to CFLAGS". Can anyone provide a short and
accurate description of when to do this?

regards, tom lane

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

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

His updates deal only with the LDLIBRARY path issue, which I think we
are keeping for 7.4:

*** ./doc/FAQ_SCO.orig  Wed Nov  6 21:35:46 2002
--- ./doc/FAQ_SCO       Wed Nov  6 21:40:44 2002
***************
*** 71,76 ****
--- 71,79 ----

configure --with-libs=/usr/local/lib --with-includes=/usr/local/include

+ You will also need to set LD_LIBRARY_PATH to '/usr/local/lib' (or add it to
+ LD_LIBRARY_PATH, if LD_LIBRARY_PATH already exists) before running config-
+ ure or the test for readline will fail.

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

Larry Rosenman wrote:

With or withou Billie's update(s)?

(I haven't looked at them)....

LER

--On Thursday, November 07, 2002 17:08:04 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

We do point to the FAQ_SCO file for specifics. Would you send a diff
for that file?

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

Larry Rosenman wrote:

For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare
7.1.2), Including
the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS or
the CC environment
variable.

--On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane
<tgl@sss.pgh.pa.us> wrote:

Larry Rosenman <ler@lerctr.org> writes:

It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3.
Apparently a compiler
fix between the 7.1.1b FS and 7.1.2.

Well, this is what the REMARKS column is for in the supported-platform
list. Seems we need a comment like "for older compiler versions, you
may need to add -Xb to CFLAGS". Can anyone provide a short and
accurate description of when to do this?

regards, tom lane

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

OK, I'll try and do up a diff to B5's tonite (probably late, my Daughter's
elementary school honors choir has a performance tonite).

LER

--On Thursday, November 07, 2002 17:44:37 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

His updates deal only with the LDLIBRARY path issue, which I think we
are keeping for 7.4:

*** ./doc/FAQ_SCO.orig  Wed Nov  6 21:35:46 2002
--- ./doc/FAQ_SCO       Wed Nov  6 21:40:44 2002
***************
*** 71,76 ****
--- 71,79 ----

configure --with-libs=/usr/local/lib --with-includes=/usr/local/include

+ You will also need to set LD_LIBRARY_PATH to '/usr/local/lib' (or add
it to + LD_LIBRARY_PATH, if LD_LIBRARY_PATH already exists) before
running config- + ure or the test for readline will fail.

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

Larry Rosenman wrote:

With or withou Billie's update(s)?

(I haven't looked at them)....

LER

--On Thursday, November 07, 2002 17:08:04 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

We do point to the FAQ_SCO file for specifics. Would you send a diff
for that file?

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

Larry Rosenman wrote:

For compilers earlier than the one released with OpenUNIX
8.0.0(UnixWare 7.1.2), Including
the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS
or the CC environment
variable.

--On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane
<tgl@sss.pgh.pa.us> wrote:

Larry Rosenman <ler@lerctr.org> writes:

It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3.
Apparently a compiler
fix between the 7.1.1b FS and 7.1.2.

Well, this is what the REMARKS column is for in the
supported-platform list. Seems we need a comment like "for older
compiler versions, you may need to add -Xb to CFLAGS". Can anyone
provide a short and accurate description of when to do this?

regards, tom lane

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

---------------------------(end of
broadcast)--------------------------- TIP 3: if posting/reading
through Usenet, please send an appropriate subscribe-nomail command
to majordomo@postgresql.org so that your message can get through to
the mailing list cleanly

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

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

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

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 |

Peter Eisentraut wrote:

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.

I disagree that it's a new feature. The code to add the -rpath (-R) option
was already there. My patch made it more useful in that the additional search
libraries are now placed in the -rpath (-R) option. As to doing it on all
platforms, that would be a decision for the maintainers of that platforms port.
It may not be necessary for it to occur on a particular platform. The patch
to Makefile.global.in provides the means by which the individual ports can add
the additional search paths. It's up to the port maintainers to decide if
it's needed for their port, IMHO.
--
____ | 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

Many thanks Larry,

Sorry I had omited the -Xb (no secret dance) in my report...

On Thu, 7 Nov 2002, Larry Rosenman wrote:

Date: Thu, 07 Nov 2002 15:17:28 -0600
From: Larry Rosenman <ler@lerctr.org>
To: Peter Eisentraut <peter_e@gmx.net>, Olivier PRENANT <ohp@pyrenet.fr>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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 22:21:56 +0100 Peter Eisentraut
<peter_e@gmx.net> wrote:

Olivier PRENANT writes:

I don't mind having CFLAGS=-Xb though, done it for php already...
By everyone says this should go off so..

The idea of the platform testing is not to determine whether you can
compile PostgreSQL after performing a secret dance. If it doesn't compile
with the default options, please don't report it as supported.

It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3. Apparently a
compiler
fix between the 7.1.1b FS and 7.1.2.

The -Xb switch is NOT a secret dance. It's needed for LOTS of open source
stuff.

See the discussion from the Caldera folks last week.

Tom's fix fixed the defaults for 7.1.2+

--
Peter Eisentraut peter_e@gmx.net

--
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)

Here is diff. Please let me know if you need better wording.

--On Thursday, November 07, 2002 16:50:26 -0600 Larry Rosenman
<ler@lerctr.org> wrote:

OK, I'll try and do up a diff to B5's tonite (probably late, my
Daughter's elementary school honors choir has a performance tonite).

LER

--On Thursday, November 07, 2002 17:44:37 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

His updates deal only with the LDLIBRARY path issue, which I think we
are keeping for 7.4:

*** ./doc/FAQ_SCO.orig  Wed Nov  6 21:35:46 2002
--- ./doc/FAQ_SCO       Wed Nov  6 21:40:44 2002
***************
*** 71,76 ****
--- 71,79 ----

configure --with-libs=/usr/local/lib --with-includes=/usr/local/include

+ You will also need to set LD_LIBRARY_PATH to '/usr/local/lib' (or add
it to + LD_LIBRARY_PATH, if LD_LIBRARY_PATH already exists) before
running config- + ure or the test for readline will fail.

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

Larry Rosenman wrote:

With or withou Billie's update(s)?

(I haven't looked at them)....

LER

--On Thursday, November 07, 2002 17:08:04 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

We do point to the FAQ_SCO file for specifics. Would you send a diff
for that file?

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

Larry Rosenman wrote:

For compilers earlier than the one released with OpenUNIX
8.0.0(UnixWare 7.1.2), Including
the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS
or the CC environment
variable.

--On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane
<tgl@sss.pgh.pa.us> wrote:

Larry Rosenman <ler@lerctr.org> writes:

It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3.
Apparently a compiler
fix between the 7.1.1b FS and 7.1.2.

Well, this is what the REMARKS column is for in the
supported-platform list. Seems we need a comment like "for older
compiler versions, you may need to add -Xb to CFLAGS". Can anyone
provide a short and accurate description of when to do this?

regards, tom lane

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

---------------------------(end of
broadcast)--------------------------- TIP 3: if posting/reading
through Usenet, please send an appropriate subscribe-nomail command
to majordomo@postgresql.org so that your message can get through to
the mailing list cleanly

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

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

Larry Rosenman <ler@lerctr.org> writes:

+For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare
+7.1.2), Including the 7.1.1b Feature Supplement, you may need to specify -Xb
+ in CFLAGS or the  CC environment variable.  The indication of this is an
+error in compiling tuplesort.c referencing inline parameters. 

s/inline parameters/inline functions/. Otherwise looks good.

regards, tom lane

Do y'all want a new diff, or can you deal with it when you do the patch?

LER

--On Friday, November 08, 2002 09:45:44 -0500 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

Larry Rosenman <ler@lerctr.org> writes:

+For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare
+7.1.2), Including the 7.1.1b Feature Supplement, you may need to
specify -Xb + in CFLAGS or the  CC environment variable.  The indication
of this is an +error in compiling tuplesort.c referencing inline
parameters.

s/inline parameters/inline functions/. Otherwise looks good.

regards, tom lane

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

I will deal with it when I apply.

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

Larry Rosenman wrote:

Do y'all want a new diff, or can you deal with it when you do the patch?

LER

--On Friday, November 08, 2002 09:45:44 -0500 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

Larry Rosenman <ler@lerctr.org> writes:

+For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare
+7.1.2), Including the 7.1.1b Feature Supplement, you may need to
specify -Xb + in CFLAGS or the  CC environment variable.  The indication
of this is an +error in compiling tuplesort.c referencing inline
parameters.

s/inline parameters/inline functions/. Otherwise looks good.

regards, tom lane

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

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

Patch applied to 7.3 and CVS, with Tom's correction.

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

Larry Rosenman wrote:

Here is diff. Please let me know if you need better wording.

--On Thursday, November 07, 2002 16:50:26 -0600 Larry Rosenman
<ler@lerctr.org> wrote:

OK, I'll try and do up a diff to B5's tonite (probably late, my
Daughter's elementary school honors choir has a performance tonite).

LER

--On Thursday, November 07, 2002 17:44:37 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

His updates deal only with the LDLIBRARY path issue, which I think we
are keeping for 7.4:

*** ./doc/FAQ_SCO.orig  Wed Nov  6 21:35:46 2002
--- ./doc/FAQ_SCO       Wed Nov  6 21:40:44 2002
***************
*** 71,76 ****
--- 71,79 ----

configure --with-libs=/usr/local/lib --with-includes=/usr/local/include

+ You will also need to set LD_LIBRARY_PATH to '/usr/local/lib' (or add
it to + LD_LIBRARY_PATH, if LD_LIBRARY_PATH already exists) before
running config- + ure or the test for readline will fail.

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

Larry Rosenman wrote:

With or withou Billie's update(s)?

(I haven't looked at them)....

LER

--On Thursday, November 07, 2002 17:08:04 -0500 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:

We do point to the FAQ_SCO file for specifics. Would you send a diff
for that file?

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

Larry Rosenman wrote:

For compilers earlier than the one released with OpenUNIX
8.0.0(UnixWare 7.1.2), Including
the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS
or the CC environment
variable.

--On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane
<tgl@sss.pgh.pa.us> wrote:

Larry Rosenman <ler@lerctr.org> writes:

It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3.
Apparently a compiler
fix between the 7.1.1b FS and 7.1.2.

Well, this is what the REMARKS column is for in the
supported-platform list. Seems we need a comment like "for older
compiler versions, you may need to add -Xb to CFLAGS". Can anyone
provide a short and accurate description of when to do this?

regards, tom lane

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

---------------------------(end of
broadcast)--------------------------- TIP 3: if posting/reading
through Usenet, please send an appropriate subscribe-nomail command
to majordomo@postgresql.org so that your message can get through to
the mailing list cleanly

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

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

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

Billy G. Allie writes:

I disagree that it's a new feature. The code to add the -rpath (-R) option
was already there. My patch made it more useful in that the additional search
libraries are now placed in the -rpath (-R) option.

Yeah, you're doing additional things, so it's a new feature. The fact
that you were able to reuse existing code is commendable but does not
create an exception.

As to doing it on all platforms, that would be a decision for the
maintainers of that platforms port.

The "rpath" feature behaves consistently across platforms and PostgreSQL
makes consistent use of it, so it does not qualify as a porting issue.
The last thing I'd want to see is that every platform looks for the
libraries in different ways.

--
Peter Eisentraut peter_e@gmx.net