Re: [HACKERS] Feb. 15 snapshot doesn't compile on alpha / Digital Unix (fwd) - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [HACKERS] Feb. 15 snapshot doesn't compile on alpha / Digital Unix (fwd) |
Date | |
Msg-id | 199802181557.KAA17350@candle.pha.pa.us Whole thread Raw |
In response to | Feb. 15 snapshot doesn't compile on alpha / Digital Unix (fwd) ("Pedro J. Lobo" <pjlobo@euitt.upm.es>) |
List | pgsql-hackers |
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
pgsql-hackers by date: