Обсуждение: UnixWare
Does anybody use postgres on this animal? UNIX_SV its-sp 4.2MP 2.1.2 i386 x86at SCO UNIX_SVR4 UX:cc: INFO: Optimizing C Compilation System (CCS) 3.0 09/26/96 (u211mr1)Postgres 6.5 current CVS I have problem to configure: >> dms@its-sp:~/current/pgsql/src>./configure >> --with-template=unixware --without-CXX >> checking whether the C compiler (cc -O -K i486,host,inline,loop_unroll,alloca >> -Dsvr4 ) works... no >> configure: error: installation or configuration problem: C compiler cannot >> create executables. ether: >> dms@its-sp:~/current/pgsql/src>./configure --with-template=unixware >> --without-CXX >> include/config.h is unchanged >> linking ./backend/port/tas/dummy.s to backend/port/tas.s >> linking ./backend/port/dynloader/unknown.c to backend/port/dynloader.c >> configure: error: ./backend/port/dynloader/unknown.c: File not found --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net * There will come soft rains ...
It looks like you are using SCO UnixWare 2.1.2. PostgreSQL 6.4.X and 6.5.X do compile and run on SCO UnixWare 7, the current version. I have not been able to compile PostgreSQL 6.5 (or any other version) on UnixWare 2. The main problem seems to be that PostgreSQL uses alloca, and I can't find the alloca.h header on my UnixWare 2 system. SCO has released a newer compiler, often called the Universal Development Kit (UDK) which will run on UnixWare 7, UnixWare 2, and OpenServer 5, and which will produce a single binary for all three platforms. PostgreSQL 6.5 will compile on both UnixWare 7 and OpenServer 5 using SCO's UDK compiler, so I assume it would compile on UnixWare 2 using it as well. However, I don't have a UnixWare 2 system with the UDK installed to test this. I hope this is helpful. Andrew Merrill The Computer Classroom, Inc., a SCO Authorized Education Center > Does anybody use postgres on this animal? > > UNIX_SV its-sp 4.2MP 2.1.2 i386 x86at SCO UNIX_SVR4 > UX:cc: INFO: Optimizing C Compilation System (CCS) 3.0 09/26/96 (u211mr1) > Postgres 6.5 current CVS
I don't know about this specific problem, but GNU has an alloca implementation that is portable enough to run on any platform (through clever trickery). So that should be solvable. Andrew Merrill wrote: > > It looks like you are using SCO UnixWare 2.1.2. PostgreSQL 6.4.X and 6.5.X do > compile and run on SCO UnixWare 7, the current version. > > I have not been able to compile PostgreSQL 6.5 (or any other version) on > UnixWare 2. The main problem seems to be that PostgreSQL uses alloca, > and I can't find the alloca.h header on my UnixWare 2 system. > > SCO has released a newer compiler, often called the Universal Development > Kit (UDK) which will run on UnixWare 7, UnixWare 2, and OpenServer 5, and > which will produce a single binary for all three platforms. PostgreSQL 6.5 > will compile on both UnixWare 7 and OpenServer 5 using SCO's UDK compiler, > so I assume it would compile on UnixWare 2 using it as well. However, > I don't have a UnixWare 2 system with the UDK installed to test this. > > I hope this is helpful. > > Andrew Merrill > The Computer Classroom, Inc., a SCO Authorized Education Center > > > Does anybody use postgres on this animal? > > > > UNIX_SV its-sp 4.2MP 2.1.2 i386 x86at SCO UNIX_SVR4 > > UX:cc: INFO: Optimizing C Compilation System (CCS) 3.0 09/26/96 (u211mr1) > > Postgres 6.5 current CVS -- Chris Bitmead mailto:chris@tech.com.au http://www.techphoto.org - Photography News, Stuff that Matters
On 17-Jun-99 Andrew Merrill wrote: > It looks like you are using SCO UnixWare 2.1.2. PostgreSQL 6.4.X and 6.5.X > do > compile and run on SCO UnixWare 7, the current version. > > I have not been able to compile PostgreSQL 6.5 (or any other version) on > UnixWare 2. The main problem seems to be that PostgreSQL uses alloca, > and I can't find the alloca.h header on my UnixWare 2 system. > > SCO has released a newer compiler, often called the Universal Development > Kit (UDK) which will run on UnixWare 7, UnixWare 2, and OpenServer 5, and > which will produce a single binary for all three platforms. PostgreSQL 6.5 > will compile on both UnixWare 7 and OpenServer 5 using SCO's UDK compiler, > so I assume it would compile on UnixWare 2 using it as well. However, > I don't have a UnixWare 2 system with the UDK installed to test this. Thank you! I found another compiler under /udk/usr/ccs/bin, and try to use it, but I have lots of configure problems yet. PS:I'm completly new in UNIXWARE, sorry for some kind of stupidity in my questions ;-)) --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net * There will come soft rains ...
On Thu, 17 Jun 1999, Dmitry Samersoff wrote:
> On 17-Jun-99 Andrew Merrill wrote:
> > compile and run on SCO UnixWare 7, the current version.
> > I have not been able to compile PostgreSQL 6.5 (or any other version) on
> > UnixWare 2. The main problem seems to be that PostgreSQL uses alloca,
> > and I can't find the alloca.h header on my UnixWare 2 system.
Ouch! Wrong! I am running UnixWare 2.1.2 and PostgreSQL 6.3.2
with good effect. In my shop we are saddled with a legacy SCO box that
I will not be sinking any additional monies into. (We don't plan to
buy any other SCO products having already purchased enough to draw
a conclusion or two. ;-)
Anyway, rhetoric aside, here is my log on how I compiled using the
stock compiler. Many thanks to Bruce Momjian who walked me through this.
Andrew, you do have alloca.h on your UW 2.1.2. It's in /usr/ucblib.
You needed to tell the linker where to find it (see below).
Kak dela Dmitri, and good luck with this. Remember Bruce M is a valuable
resource and I will also try to help you as much as I am able before you
feel a need to throw money at SCO.
Dobri den (forgive fonetic Rooski! No cyrillic char set...),
Tom
/**** PostgreSQL Installation ***/
1) # useradd postgres
2) # mkdir /usr/local/pgsql
3) # mkdir /usr/src/pgsql
4) # chown postgres /usr/local/pgsql
5) # chown postgres /usr/src/pgsql
6) # chgrp other /usr/local/pgsql
7) # chgrp other /usr/src/pgsql
8) # /usr/local/bin/gunzip /usr/spool/uucppublic/postgres-6.3.2.tar.gz
9) # su - postgres
10) $ cd /usr/src/pgsql
11) $ tar xvf /usr/spool/uucppublic/postgres-6.3.2.tar
12) $ cd ./post*
13) $ cd ./src
14) $ cp configure configure.orig
15) $ vi configure... /TEMPLATE change TEMPLATE=template/`uname -s | tr A-Z a-z` to TEMPLATE=template/univel
16) $ gmake all >&make.log & flex barfs: unable to locate /home/local/lib/flex.skel FIX: download
flex-2.3pl7.tar.Z # /usr/local/bin/gunzip /var/spool/uucppublic/flex-2.3pl7.pkg.tar.Z # tar xvf flex-2.3pl7.pkg.tar
# pkgadd -d `pwd` # ln -sf /opt/bin/flex /usr/local/bin/flex
17) $ gmake all >&make.log & bison barfs... FIX: download bison-1.14.pkg.tar.Z # /usr/local/bin/gunzip
/var/spool/uucppublic/bison-1.14.pkg.tar.Z # tar xvf bison-1.14.pkg.tar # pkgadd -d `pwd` # ln -sf /opt/bin/bison
/usr/local/bin/bison
18) After a multitude of warnings, gmake barfs with: Undefined symbol alloca in file bootstrap/SUBSYS.o
Searchedlibraries: # nm /usr/lib/*.so* | grep alloca # nm /usr/lib/*.a* | grep alloca
# nm /usr/ccs/lib/*.so* | grep alloca # nm /usr/ccs/lib/*.a* | grep alloca
# nm /usr/ucblib/*.so* | grep alloca # nm /usr/ucblib/*.a* | grep alloca
FIX:tail make.log > fixer...edit to add calls to Berkeley libraries ( -L/usr/ucblib -lucb )
cd /usr/src/pgsql/postgresql-6.3.2/src/backend cc -o postgres access/SUBSYS.o bootstrap/SUBSYS.o
catalog/SUBSYS.ocommands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o
optimizer/SUBSYS.oparser/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUB SYS.o
storage/SUBSYS.otcop/SUBSYS.o utils/SUBSYS.o ../utils/version.o -L/usr/ucblib -lucb -lgen -lcrypt -lld -lnsl
-lsocket-ldl -lm -ltermcap -lcurses -lc89 -lc89 -Wl,-Bexport
19) After compiling the backend, gmake all barfs when compiling ecpg: Undefined first referenced symbol
in file yyout y.tab.o yylex y.tab.o
yyin ecpg.o yytext y.tab.o alloca
y.tab.o yylineno y.tab.o lex_init ecpg.o yyleng
y.tab.o UX:ld: ERROR: ecpg: fatal error: Symbol referencing errors. No output written to ecpg
gmake[3]: *** [ecpg] Error 1 gmake[2]: *** [all] Error 2 gmake[1]: *** [all] Error 2 gmake: *** [all] Error 2
Searchingall the library files (/usr/lib, /usr/ccs/lib and /usr/ucblib) with # nm *.so* | grep $file (yy---, alloca
andlex_init) and # nm *.a* | grep $file (yy---, alloca and lex_init) revealed that lex_init does not exist on this
box. FIX: comment ecpg out of the ./interfaces/Makefile
20) postgres user was unable to run initdb... FIX: edit /etc/profile:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib export LD_LIBRARY_PATH then: $ initdb --username=postgres
succeeded.
21) Attempting to fire up the server produced IpcMemoryCreate errors. FIX: enlarge shared memory avail in the
kernel... # /etc/conf/bin/idtune SHMMAX 778240 # /etc/conf/bin/idbuild -B
22) Installed DBI::DBD in usual manner but perl is too old (5.003). Downloading 5.004_04 from
www.sco.com/skunkware/uw2/interp/perl/
23) Installed Perl 5.004_04 and reinstalled DBI::DBD Error msg when trying to run a dbi script: dynamic linker:
/usr/bin/perl:symbol not found: strncasecmp FIX: edit /usr/src/perl5/DBD*/Pg.xs, replacing strncasecmp with strncmp
---rerun `make' & `make install'.
if (!strncmp(statement, "begin", 5) || !strncmp(statement, "end", 4) || !strncmp(statement,
"commit", 6) || !strncmp(statement, "abort", 5) || !strncmp(statement, "rollback", 8) ) { if
(!strncmp(statement,"begin", 5) || !strncmp(statement, "end", 4) || !strncmp(statement, "commit",
6)|| !strncmp(statement, "abort", 5) || !strncmp(statement, "rollback", 8) ) {
EOF
> I found another compiler under /udk/usr/ccs/bin, and try to use it,
> but I have lots of configure problems yet.
>
> PS:
> I'm completly new in UNIXWARE, sorry for some kind of stupidity in my
> questions ;-))
>
>
> ---
> Dmitry Samersoff, dms@wplus.net, ICQ:3161705
> http://devnull.wplus.net
> * There will come soft rains ...
>
------- North Richmond Community Mental Health Center -------
Thomas Good MIS Coordinator
Vital Signs: tomg@ { admin | q8 } .nrnet.org Phone:
718-354-5528 Fax: 718-354-5056
/* Member: Computer Professionals For Social Responsibility */
> It looks like you are using SCO UnixWare 2.1.2. PostgreSQL 6.4.X and 6.5.X do > compile and run on SCO UnixWare 7, the current version. > > I have not been able to compile PostgreSQL 6.5 (or any other version) on > UnixWare 2. The main problem seems to be that PostgreSQL uses alloca, > and I can't find the alloca.h header on my UnixWare 2 system. Alloca source should be available somewhere for your platform. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Hi Thomas G. and Dmitry. Could you think about melding these
instructions onto doc/FAQ_SCO in the v6.5 distribution? It currently
omits mention of UnixWare2.0, but istm that this cookbook could be
added to the end with great effect. Perhaps Andrew could do the actual
graft...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Andrew Merrill <andrew@thatch2.compclass.com> writes:
> It looks like you are using SCO UnixWare 2.1.2. PostgreSQL 6.4.X and 6.5.X do
> compile and run on SCO UnixWare 7, the current version.
> I have not been able to compile PostgreSQL 6.5 (or any other version) on
> UnixWare 2. The main problem seems to be that PostgreSQL uses alloca,
> and I can't find the alloca.h header on my UnixWare 2 system.
Here is another line of attack besides the ones already given. I've
been around on this problem with HPUX 9, and find that the only places
in PostgreSQL that use alloca are the parser files, and those do so only
if they were generated with GNU bison. But the prebuilt copies of
gram.c and preproc.c are made with bison. So, one solution is to
rebuild the parser files with your local yacc --- which, presumably,
will not generate code that relies on alloca.
Vendor yaccs tend to spit up on the Postgres grammar files because
they're so large, so this may be easier said than done. See
doc/FAQ_HPUX for a set of yacc switches that worked for me.
Of course, the other approach is to install and use gcc, which supports
alloca as inline code on all platforms...
regards, tom lane
On 17-Jun-99 Thomas Good wrote: > On Thu, 17 Jun 1999, Dmitry Samersoff wrote: > >> On 17-Jun-99 Andrew Merrill wrote: >> > compile and run on SCO UnixWare 7, the current version. > >> > I have not been able to compile PostgreSQL 6.5 (or any other version) on >> > UnixWare 2. The main problem seems to be that PostgreSQL uses alloca, >> > and I can't find the alloca.h header on my UnixWare 2 system. > > Ouch! Wrong! I am running UnixWare 2.1.2 and PostgreSQL 6.3.2 > with good effect. In my shop we are saddled with a legacy SCO box that > I will not be sinking any additional monies into. (We don't plan to > buy any other SCO products having already purchased enough to draw > a conclusion or two. ;-) > > Anyway, rhetoric aside, here is my log on how I compiled using the > stock compiler. Many thanks to Bruce Momjian who walked me through this. I keep it simple (for 6.5 release)! I patch configure.in sysv4.2*) case "$host_vendor" in univel) os=univel need_tas=no ;; + pc) os=uw2 need_tas=no ;; *) os=unknown need_tas=no ;; esac ;; and setup apropriate template and port/* files Template really could be set to "unixware", but I have strange directory /udk/usr/ .... where all libraries and includes reside. gmake ofcause should be installed, but I use gmake for my-own development so it don't case trouble. I receive strange lex error ex scan.l "scan.l":line 55: Error: Invalid request %x IN_STRING IN_COMMENT gmake: *** [pl_scan.c] Error 1 scan.l:55 %x IN_STRING IN_COMMENT What it means? I'm going to install flex. > Kak dela Dmitri, and good luck with this. Remember Bruce M is a valuable > resource and I will also try to help you as much as I am able before you > feel a need to throw money at SCO. Thanks alot for good wishes!We don't plan to spend many for SCO, but old UW is part of Lucent Voice-over-IP solution and I need to do some magic with UW to make it managable by our support dept. --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net * There will come soft rains ...
Andrew Merrill wrote: > It looks like you are using SCO UnixWare 2.1.2. PostgreSQL 6.4.X and 6.5.X d > o > compile and run on SCO UnixWare 7, the current version. > > I have not been able to compile PostgreSQL 6.5 (or any other version) on > UnixWare 2. The main problem seems to be that PostgreSQL uses alloca, > and I can't find the alloca.h header on my UnixWare 2 system. > > SCO has released a newer compiler, often called the Universal Development > Kit (UDK) which will run on UnixWare 7, UnixWare 2, and OpenServer 5, and > which will produce a single binary for all three platforms. PostgreSQL 6.5 > will compile on both UnixWare 7 and OpenServer 5 using SCO's UDK compiler, > so I assume it would compile on UnixWare 2 using it as well. However, > I don't have a UnixWare 2 system with the UDK installed to test this. > > I hope this is helpful. > > Andrew Merrill > The Computer Classroom, Inc., a SCO Authorized Education Center > > > Does anybody use postgres on this animal? > > > > UNIX_SV its-sp 4.2MP 2.1.2 i386 x86at SCO UNIX_SVR4 > > UX:cc: INFO: Optimizing C Compilation System (CCS) 3.0 09/26/96 (u211mr1 > ) > > Postgres 6.5 current CVS > Under UnixWare 2.x, alloca is in the UCB library (libucb.a ?). The easist way to link in alloca is to extract it from libucb.a and either link in the alloca.o file or put it into the libgen.a library and the link in via -lgen. Why now just link in lubucb.a you ask? The are routines in libucb.a that you do not want to get linked into the object in place of the regular routines with the same name. I have ran my UnixWare 2.x system (when I had it) with alloca in libgen.a with out any problems. This was the setup I used to compile Postgres 6.3.x when I had UnixWare 2.x. [Hmmm.... It looks like I should put together a 486 box to run Unixware 2.x on so that I can test new versions of PostgreSQL on it]. -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 |
On Thu, 17 Jun 1999, Billy G. Allie wrote:
Billy,
I have such a box (running 2.1.2 and pg 6.3.2) and linked no problem (see
earlier post) by telling the linker to use /usr/ucblib.
Thomas Lockhart would like me to document this along with Dmitri S and
Andrew...but I am underqualifed (generally ;-)
Care to assist?
Cheers,
Tom Good
> Under UnixWare 2.x, alloca is in the UCB library (libucb.a ?). The easist way
> to link in alloca is to extract it from libucb.a and either link in the
> alloca.o file or put it into the libgen.a library and the link in via -lgen.
> Why now just link in lubucb.a you ask? The are routines in libucb.a that you
> do not want to get linked into the object in place of the regular routines
> with the same name. I have ran my UnixWare 2.x system (when I had it) with
> alloca in libgen.a with out any problems.
>
> This was the setup I used to compile Postgres 6.3.x when I had UnixWare 2.x.
> [Hmmm.... It looks like I should put together a 486 box to run Unixware 2.x
> on so that I can test new versions of PostgreSQL on it].
>
> --
> ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
> | /| | 7436 Hartwell | Compuserve: 76337,2061
> |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
> |/ |LLIE | (313) 582-1540 |
>
>
>
------- North Richmond Community Mental Health Center -------
Thomas Good MIS Coordinator
Vital Signs: tomg@ { admin | q8 } .nrnet.org Phone:
718-354-5528 Fax: 718-354-5056
/* Member: Computer Professionals For Social Responsibility */
On 18-Jun-99 Thomas Good wrote: > On Thu, 17 Jun 1999, Billy G. Allie wrote: > > Billy, > > I have such a box (running 2.1.2 and pg 6.3.2) and linked no problem (see > earlier post) by telling the linker to use /usr/ucblib. I clearly build 6.5 on my UW using compiler located in /udk with one fiew problem in plpgsql: compilation of pl_scan.c filed due undeclared K_ALIAS ... I move line #include "pl_scan.c" in pl_gram.c after constant declaration, but I don't now how it can be solved permanently in gram.y I can't connect to postgres using UDS, probably, because its on disk name has additional simbol ^F root@its-sp:~/postgresql-6.5/src/pl/plpgsql/src>ls -l /tmp/.s* p-w--w--w- 1 postgres 0 Jun 17 22:39 /tmp/.s.PGSQL.5432^F --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net * There will come soft rains ...
Dmitry Samersoff wrote: > > On 18-Jun-99 Thomas Good wrote: > > On Thu, 17 Jun 1999, Billy G. Allie wrote: > > > > Billy, > > > > I have such a box (running 2.1.2 and pg 6.3.2) and linked no problem (see > > earlier post) by telling the linker to use /usr/ucblib. > > I clearly build 6.5 on my UW using compiler located in /udk > with one fiew problem in plpgsql: > compilation of pl_scan.c filed due undeclared > K_ALIAS ... > [...] > > I can't connect to postgres using UDS, > probably, because its on disk name has additional simbol ^F > > root@its-sp:~/postgresql-6.5/src/pl/plpgsql/src>ls -l /tmp/.s* > p-w--w--w- 1 postgres 0 Jun 17 22:39 /tmp/.s.PGSQL.5432^F I had a similar problem on UnixWare 7.x, except mine had a control-D (most of the time). The problem went away after I applied the current patches to the system (surprise, surprise). I would suggest bringing your system up to 2.1.3 with all the patches applied. It is a problem with Unixware. The othersolution is to only use TCP/IP to connect to the database, even on the local machine. You can do this with the -i option to postmaster. I hope this helps. > --- > Dmitry Samersoff, dms@wplus.net, ICQ:3161705 > http://devnull.wplus.net > * There will come soft rains ... > -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 |