UnixWare

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

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
Searched libraries: # 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.o commands/SUBSYS.o executor/SUBSYS.o
lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o
optimizer/SUBSYS.o parser/SUBSYS.o port/SUBSYS.o
postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUB
SYS.o storage/SUBSYS.o tcop/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
Searching all the library files (/usr/lib, /usr/ccs/lib and /usr/ucblib)
with # nm *.so* | grep $file (yy---, alloca and lex_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, Pennsylvania 19026

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