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)