Feb. 15 snapshot doesn't compile on alpha / Digital Unix (fwd)

OK, where are we with Alpha now? Dec Unix and Alpha Linux users, what
is your status. Is anyone geting through initdb, and if so, how?

Hi, all.

I'm forwarding this message I posted to psql-ports, because I've seen no
answer on it, and the D-day approaches...

---------- Forwarded message ----------
Date: Mon, 16 Feb 1998 12:48:49 +0100 (MET)
From: "Pedro J. Lobo" <pjlobo@euitt.upm.es>
To: PostgreSQL ports mailing list <pgsql-ports@postgresql.org>
Subject: Feb. 15 snapshot doesn't compile on alpha / Digital Unix

Hi, folks.

The good news: I compiled 6.3 beta on Digital Unix 3.2c using the DEC C
compiler.

The bad news: It doesn't work :-(

It compiles and installs well, but initdb fails. This is the output
message:

------------------------------------------------------------
initdb: using /usr/local/pgsql.beta/lib/local1_template1.bki.source as
input to create the template database.
initdb: using /usr/local/pgsql.beta/lib/global1.bki.source as input to
create the global classes.
initdb: using /usr/local/pgsql.beta/lib/pg_hba.conf.sample as the
host-based authentication control file.

We are initializing the database system with username pgbeta (uid=104).
This user will own all the files and must also own the server process.

Creating Postgres database system directory /usr/local/pgsql.beta/data

Creating Postgres database system directory /usr/local/pgsql.beta/data/base

initdb: creating template database in /usr/local/pgsql.beta/data/base/template1
Running: postgres -boot -C -F -D/usr/local/pgsql.beta/data -Q template1
ERROR: BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
ERROR: BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
longjmp or siglongjmp function used outside of saved context
/usr/local/pgsql.beta/bin/initdb: 420 Abort - core dumped
initdb: could not create template database
initdb: cleaning up by wiping out /usr/local/pgsql.beta/data/base/template1
-----------------------------------------------------------

This is the GDB stack trace from the core file:

----------------------------------------------------------
GDB 4.16 (alpha-dec-osf3.2), Copyright 1996 Free Software Foundation, Inc...
Core was generated by `postgres'.
Program terminated with signal 6, IOT/Abort trap.
Reading symbols from /usr/shlib/libm.so...done.
Reading symbols from /usr/shlib/libcurses.so...done.
Reading symbols from /usr/shlib/libc.so...done.
Reading symbols from /usr/lib/nls/loc//es_ES.ISO8859-1...done.
#0 0x3ff8010cf28 in kill ()
(gdb) where
#0 0x3ff8010cf28 in kill ()
#1 0x3ff801218f4 in raise ()
#2 0x3ff8010fd44 in abort ()
#3 0x3ff80102e20 in _longjmp ()
#4 0x3ff80105778 in siglongjmp ()
#5 0x120144d24 in handle_warn (postgres_signal_arg=1) at postgres.c:736
#6 <signal handler called>
#7 0x3ff8010cf28 in kill ()
#8 0x12018deb8 in elog (lev=-1,
fmt=0x14002f8d8 "%s: function %s(%s) does not exist", ...=0x140011428)
at elog.c:180
#9 0x12010ddd4 in func_error (caller=0x140011428 "BuildFuncTupleDesc",
funcname=0x11ffff260 "mkoidname", nargs=2, argtypes=0x11ffff23c)
at parse_func.c:1307
#10 0x120074114 in BuildFuncTupleDesc (funcInfo=0x11ffff238) at index.c:298
#11 0x120075998 in index_create (heapRelationName=0x1401bba50 "pg_attribute",
indexRelationName=0x1401dc730 "pg_attribute_relid_attnam_index",
funcInfo=0x11ffff238, attributeList=0x0, accessMethodObjectId=403,
numatts=1, attNums=0x1401dc9c0, classObjectId=0x1401dc9f0,
parameterCount=0, parameter=0x0, predicate=0x0, islossy=0 '\000',
unique=0 '\000') at index.c:1114
#12 0x1200860a4 in DefineIndex (heapRelationName=0x1401bba50 "pg_attribute",
indexRelationName=0x1401dc730 "pg_attribute_relid_attnam_index",
accessMethodName=0x1401db830 "btree", attributeList=0x1401e0a60,
parameterList=0x0, unique=0 '\000', predicate=0x0, rangetable=0x0)
at defind.c:190
#13 0x12006b580 in Int_yyparse () at /usr/local/share/bison.simple:234
#14 0x12006e80c in BootstrapMain (argc=6, argv=0x11ffffcb0) at bootstrap.c:446
#15 0x1200c51b0 in main (argc=7, argv=0x11ffffca8) at main.c:94
--------------------------------------------------------------

I have no knowledge of postgres internals, but I have experience in C/C++
programming (and debugging) and can help if someone gives me a clue. The
same hardware/OS/compiler combination works well with 6.2.1p6.

In case it matters, this is the configure command that I've used:

./configure --prefix=/usr/local/pgsql.beta --enable-locale
--with-pgport=5440 --enable-cassert --with-compiler=cc

I have my production database (6.2.1p6) running on the same machine on the
standard port (5432), but I don't think it has any adverse effect. In
fact, postgres -boot doesn't do any socket communications, does it? The
production database is stored completely on another tree
(/usr/local/pgsql instead of /usr/local/pgsql.beta).

BTW, I had to patch 'configure' to handle --with-compiler correctly. This
is an old problem, and I will report it more extensively in another
message.

-------------------------------------------------------------------
Pedro Jos��� Lobo Perea Tel: +34 1 336 78 19
Centro de C���lculo Fax: +34 1 331 92 29
EUIT Telecomunicaci���n - UPM e-mail: pjlobo@euitt.upm.es

--
Bruce Momjian
maillist@candle.pha.pa.us