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

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

From

"Pedro J. Lobo"

Date:

18 February 1998, 13:51:10

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

Re: [HACKERS] Feb. 15 snapshot doesn't compile on alpha / Digital Unix (fwd)

From

Bruce Momjian

Date:

18 February 1998, 14:40:24

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