Second call for platform testing

Thomas Lockhart wrote:

The following platforms have been reported as successfully running
PostgreSQL 7.2:

AIX Andreas Zeugswetter (Tatsuo working on 5L?)
BSD/OS Bruce
FreeBSD Chris Kings-Lynne
HPUX Tom (anyone tested 11.0 or higher?)

Are you still looking for HPUX 11.0+ ? I can arrange for access to one
if we still need it (gcc though, I don't have access to HP's compiler).

-- Joe

I just tested the BeOS port (and updated the regression test database).

Two little tweaks are needed to make it compile and install :

* int8/uint8 and int64/uint64 are not detected properly by configure
(they are declared in SupportDefs.h on beos).
* data dir is created with group and world access, preventing
postmaster from starting (a simple chmod og-rwx will do)

The regression test pass without any error.

cyril

Are you still looking for HPUX 11.0+ ? I can arrange for access to one
if we still need it (gcc though, I don't have access to HP's compiler).

Yes, that would be great. 10.20 is pretty old afaik...

- Thomas

I just tested the BeOS port (and updated the regression test database).
Two little tweaks are needed to make it compile and install :
* int8/uint8 and int64/uint64 are not detected properly by configure
(they are declared in SupportDefs.h on beos).
* data dir is created with group and world access, preventing
postmaster from starting (a simple chmod og-rwx will do)
The regression test pass without any error.

Great! Can the int8 detection be helped with a patch to get the right
include file?

- Thomas

SCO OpenUNIX should be Caldera OpenUNIX....

Thanks,
LER

* Thomas Lockhart <lockhart@fourpalms.org> [011128 22:07]:

OK, the list is getting smaller fast (thanks for all of the responses!).
Here is what I have left currently (note the addition of NetBSD/sparc,
which I had inadvertently omitted from the first list):

BeOS Cyril Velter
Linux/arm Mark Knox
Linux/s390 Neale Ferguson
NetBSD/arm32 Patrick Welche
NetBSD/m68k Bill Studenmund (will test)
NetBSD/sparc Matthew Green (left off the first list)
NetBSD/VAX Tom I. Helbekkmo
QNX (did I get a definitive report for 4.x already?)
SunOS Tatsuo Ishii (old release; still relevant?)
Windows/Cygwin Daniel Horak (OK in serial test, trouble with parallel
test?)
Windows/native Magnus Hagander (clients only)

I'm curious about the Windows/Cygwin trouble, and if others see it too,
since the -cygwin mailing list seems to report happiness with 7.1.3.

Tatsuo, do you think that we should still track SunOS explicitly?

Are there any other platforms we are running on?

- Thomas

The following platforms have been reported as successfully running
PostgreSQL 7.2:

AIX Andreas Zeugswetter (Tatsuo working on 5L?)
BSD/OS Bruce
FreeBSD Chris Kings-Lynne
HPUX Tom (anyone tested 11.0 or higher?)
IRIX Luis Amigo
Linux/Alpha Tom
Linux/MIPS Hisao Shibuya
Linux/PPC Tom
Linux/sparc Doug McNaught
Linux/x86 Thomas (and many others ;)
MacOS-X Gavin Sherry
NetBSD/Alpha Thomas Thai
NetBSD/PPC Bill Studenmund
NetBSD/x86 Bill Studenmund
OpenBSD/sparc Brandon Palmer
OpenBSD/x86 Brandon Palmer
SCO OpenUnix Larry Rosenman
Solaris/sparc Andrew Sullivan
Solaris/x86 Martin Renters
Tru64 Alessio Bragadini (trouble with 5.1?)

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

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

SCO OpenUNIX should be Caldera OpenUNIX....

Got it. Thanks.

- Thomas

I just tested the BeOS port (and updated the regression test

database).

Two little tweaks are needed to make it compile and install :
* int8/uint8 and int64/uint64 are not detected properly by

configure

(they are declared in SupportDefs.h on beos).
* data dir is created with group and world access, preventing
postmaster from starting (a simple chmod og-rwx will do)
The regression test pass without any error.

Great! Can the int8 detection be helped with a patch to get the right
include file?

I think it can, but I'm not familiar at all with configure script. If
someone can point me where the change should be made, I'll make and test a
patch.

What modification should be made to configure.in to make it include
SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

cyril

What modification should be made to configure.in to make it

include

SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

Is SupportDefs.h actually (probably implicitly) included by the
PostgreSQL
source ? Because if it is not, PostgreSQL is quite happy not finding
them in
configure.

Not finding them is only a problem if you get redefines during
compilation
(and if your compiler then treats that as fatal).

Andreas

What modification should be made to configure.in to make it

include

SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

Is SupportDefs.h actually (probably implicitly) included by the
PostgreSQL
source ? Because if it is not, PostgreSQL is quite happy not finding
them in
configure.

Not finding them is only a problem if you get redefines during
compilation
(and if your compiler then treats that as fatal).

Good point. Also, a mixed-case include file is quite unusual. One idea
if you can't get it working is to either include "SupportDefs.h" for
BeOS in configure.in and c.h, or check the top of SupportDefs.h. Often
there is an #ifdef at the top to prevent the file from being included
twice. If you define that in c.h for BeOS, the include SupportDefs.h
will never be used and we can use our own defines for uint8/uint64.

FYI, this test was added for AIX in recent weeks because it had similar
trouble.

Here is the little snippet of code from configure to test for uint8:

#include "confdefs.h"
#include <stdio.h>
main()
{
FILE *f=fopen("conftestval", "w");
if (!f) exit(1);
fprintf(f, "%d\n", sizeof(uint8));
exit(0);
}

Now, we would normally modify configure.in, but you can play with
configure until you get it to work, let us know, and we can modify
configure.in, run autoconf, make any needed additions to c.h, and get it
into CVS.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

"Cyril VELTER" <cyril.velter@libertysurf.fr> writes:

What modification should be made to configure.in to make it include
SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

This looks like a bit of a pain. We're currently using AC_CHECK_SIZEOF
to make those probes, apparently because it's the closest standard macro
to what we want. But it's not close enough. It doesn't include
anything except <stdio.h>. I don't think we can fix this except by
making our own macro. Peter, any opinion about how to do it?

(If we do make our own macro, we could change the output to be something
more reasonable, like #defining HAVE_UINT8 rather than claiming
"sizeof uint8 = 0", which is sure to confuse people.)

regards, tom lane

What modification should be made to configure.in to make it include
SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

Is SupportDefs.h actually (probably implicitly) included by the
PostgreSQL
source ? Because if it is not, PostgreSQL is quite happy not finding
them in
configure.

Not finding them is only a problem if you get redefines during
compilation
(and if your compiler then treats that as fatal).

SupportDefs.h is conditionaly included in c.h so everything is Ok when I
compile the backend, but when configure try to figure out the size of int8
... they are not defined.

May be SupportDefs.h should be included from another file ?

cyril

Cyril VELTER writes:

I just tested the BeOS port (and updated the regression test database).

Two little tweaks are needed to make it compile and install :

* int8/uint8 and int64/uint64 are not detected properly by configure
(they are declared in SupportDefs.h on beos).

Well, that was the end of that bright idea. There's no way to tell
AC_CHECK_SIZEOF what header files to consider. We need to put back the
#ifdef __BEOS__, it seems.

* data dir is created with group and world access, preventing
postmaster from starting (a simple chmod og-rwx will do)

What does the shell do with the umask call in initdb?

--
Peter Eisentraut peter_e@gmx.net

"Cyril VELTER" <cyril.velter@libertysurf.fr> writes:

What modification should be made to configure.in to make it include
SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

This looks like a bit of a pain. We're currently using AC_CHECK_SIZEOF
to make those probes, apparently because it's the closest standard macro
to what we want. But it's not close enough. It doesn't include
anything except <stdio.h>. I don't think we can fix this except by
making our own macro. Peter, any opinion about how to do it?

I was wondering where that bizarre fopen()/fprintf() in the test code
came from. It looked strange. Now I know why; it came from autoconf.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

* data dir is created with group and world access, preventing
postmaster from starting (a simple chmod og-rwx will do)

What does the shell do with the umask call in initdb?

I will look at it (I'm not on a beos box right now), but as BeOS is
not a true multiuser system, he is probably faulty here.

cyril

Thomas Lockhart wrote:

Are you still looking for HPUX 11.0+ ? I can arrange for access to one
if we still need it (gcc though, I don't have access to HP's compiler).

Yes, that would be great. 10.20 is pretty old afaik...

- Thomas

I ran into a problem on HPUX 11 right off with:

===============================
configure --enable-debug
.
.
.
checking for struct sockaddr_un... yes
checking for int timezone... yes
checking types of arguments for accept()... configure: error: could not
determine argument types

===============================

I won't pretend to be very knowledgable about HPUX or configure, but it
looks like the following in configure is where it dies:

===============================

else
for ac_cv_func_accept_arg1 in 'int' 'unsigned int'; do
for ac_cv_func_accept_arg2 in 'struct sockaddr *' 'const struct
sockaddr *' 'void *'; do
for ac_cv_func_accept_arg3 in 'int' 'size_t' 'socklen_t'
'unsigned int' 'void'; do
cat > conftest.$ac_ext <<EOF

=======================================

and here's what the HPUX man page says:

=======================================
accept(2)

NAME
accept - accept a connection on a socket

SYNOPSIS
#include <sys/socket.h>

AF_CCITT only
#include <x25/x25addrstr.h>

int accept(int s, void *addr, int *addrlen);

_XOPEN_SOURCE_EXTENDED only (UNIX 98)
int accept(int s, struct sockaddr *addr, socklen_t *addrlen);

=======================================

so it looks like configure expects the third argument to be (int), when
on HPUX 11 the third argument is (int *).

Any ideas what I'm doing wrong?

-- Joe

Joe Conway <joseph.conway@home.com> writes:

I ran into a problem on HPUX 11 right off with:

That's odd, considering that someone else reported 7.1 worked fine on
HPUX 11, and we haven't changed this configure test since then.

so it looks like configure expects the third argument to be (int), when
on HPUX 11 the third argument is (int *).

No, the macro knows that the third argument is pointer-to-something;
it's trying to figure out pointer-to-what.

Any ideas what I'm doing wrong?

What had configure selected so far for compiler, cflags, etc? Maybe
it's blowing the game at that stage. Or maybe the test is failing to
include all the needed include files to define these datatypes.

In general, the config.log output is a good thing to post when puzzled
by configure problems.

regards, tom lane

Tom Lane wrote:

What had configure selected so far for compiler, cflags, etc? Maybe
it's blowing the game at that stage. Or maybe the test is failing to
include all the needed include files to define these datatypes.

In general, the config.log output is a good thing to post when puzzled
by configure problems.

OK. Figured out a couple of pieces to this. First, although I was told
we did not have HP's compiler, it is actually there. Second, since gcc
was freshly installed, it wasn't in my PATH. So the error I reported
last time is actually from the bundled compiler.

So I added /opt/gcc/bin to my PATH, and got a different error once gcc
was detected.

Attached are both config.log files. Sorry for being so clueless here,
but I haven't done much on HPUX before.

Joe

Joe Conway <joseph.conway@home.com> writes:

... So the error I reported
last time is actually from the bundled compiler.

Which, unless HP has reconsidered since HPUX 10, is a deliberately
crippled K&R (no ANSI features) compiler. It's no wonder the configure
run failed; I guess failing right at this point is happenstance, though
it could not have gotten further since this test depends on ANSI
prototypes.

configure:1361: checking whether the C compiler (cc -Ae +O2 ) works
configure:1377: cc -Ae -o conftest +O2 conftest.c 1>&5
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +O2 option is available only with the C/ANSI C product; ignored.

It's a shame configure hides all these useful messages down inside
config.log.

I wonder whether we shouldn't make the bare "does it work" test include
verification that ANSI-style prototypes are supported.

So I added /opt/gcc/bin to my PATH, and got a different error once gcc
was detected.

configure:1243: checking whether the C compiler (gcc ) works
configure:1259: gcc -o conftest conftest.c 1>&5
as: warning 2: Unknown option "--traditional-format" ignored.
as: "/var/tmp/cceTg0Kd.s", line 15: error 1052: Directive name not recognized - NSUBSPA

This looks like your gcc installation is broken: specifically, I'll bet
it's trying to use HP's assembler rather than gas. You really want the
GNU toolchain (binutils package) underneath gcc. The gcc-to-HP-as
configuration has never worked for me (though I have to admit I haven't
tried in a long time).

In the meantime, try it with HP's real compiler (set CC=cc for configure).

regards, tom lane

Thomas Lockhart wrote:

OK, the list is getting smaller fast (thanks for all of the responses!).

I got a regression test result from Hiroshi Saito on
UNIX_System_V ews4800 4.2MP 4.2 R4000 r4000.

=======================
10 of 79 tests failed.
========================

int8 ... FAILED
abstime ... FAILED
tinterval ... FAILED
test geometry ... FAILED
test horology ... FAILED
create_index ... FAILED
test sanity_check ... FAILED
test select ... FAILED
subselect ... FAILED
union ... FAILED

Seems INT64_IS_BUSTED, old PST ... etc and

*** ./expected/create_index.out	Tue Aug 28 08:23:34 JST 2001
--- ./results/create_index.out	Fri Nov 30 00:28:22 JST 2001
***************
*** 35,44 ****
--- 35,47 ----
  --
  CREATE INDEX onek2_u1_prtl ON onek2 USING btree(unique1 int4_ops)
  	where unique1 < 20 or unique1 > 980;
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f64f0
  CREATE INDEX onek2_u2_prtl ON onek2 USING btree(unique2 int4_ops)
  	where stringu1 < 'B';
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f6390
  CREATE INDEX onek2_stu1_prtl ON onek2 USING btree(stringu1 name_ops)
  	where onek2.stringu1 >= 'J' and onek2.stringu1 < 'K';
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f6740
  --
  -- RTREE
  -- 

regards,
Hiroshi Inoue