UnixWare chokes

Hi all,

Trying to build pg on unixware...hacked configure as follows
to create a Makefile:

change TEMPLATE=template/`uname -s | tr A-Z a-z`
to TEMPLATE=template/univel

Downloaded flex-2.3pl7.tar.Z from Freebird site, installed...
Downloaded bison-1.14.pkg.tar.Z and installed.

And now - after a multitude of warnings (many more than with FreeBSD
or Linux) gmake barfs with:
Undefined symbol alloca in file bootstrap/SUBSYS.o

The alloca calls are coming from the code generated by bison. Strange
it would do that on Unixware. You would think bison would know if
alloca was available, and only use it if it was. If you use 'nm' you
will see the unresolved call in bootparse.c, no?

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

On Wed, 28 Apr 1999, Bruce Momjian wrote:

or Linux) gmake barfs with:
Undefined symbol alloca in file bootstrap/SUBSYS.o

The alloca calls are coming from the code generated by bison. Strange
it would do that on Unixware. You would think bison would know if
alloca was available, and only use it if it was. If you use 'nm' you
will see the unresolved call in bootparse.c, no?

Bruce - I am not sure what I am looking for...so here is the stdout from
running nm (tail make.log follows the nm output).

Thanks for taking the time, I know you're rather busy.

Tom
---

Symbols from /usr/src/pgsql/postgresql-6.3.2/src/backend/bootstrap/bootparse.o:

[Index] Value Size Type Bind Other Shndx Name

[1]: | 0| 0|FILE |LOCL |0 |ABS |bootparse.y
[2]: | 0| 0|SECT |LOCL |0 |1 |.text
[3]: | 0| 0|SECT |LOCL |0 |2 |.data
[4]: | 0| 0|SECT |LOCL |0 |3 |.data1
[5]: | 0| 0|SECT |LOCL |0 |4 |.rodata
[6]: | 0| 0|SECT |LOCL |0 |5 |.rodata1
[7]: | 0| 0|SECT |LOCL |0 |6 |.bss
[8]: | 0| 0|SECT |LOCL |0 |7 |.comment
[9]: | 0| 4|OBJT |LOCL |0 |6 |objectid
[10]: | 0| 36|FUNC |LOCL |0 |1 |__yy_bcopy
[11]: | 1262| 130|OBJT |LOCL |0 |4 |Int_yycheck
[12]: | 1132| 130|OBJT |LOCL |0 |4 |Int_yytable
[13]: | 1086| 46|OBJT |LOCL |0 |4 |Int_yypgoto
[14]: | 944| 142|OBJT |LOCL |0 |4 |Int_yypact
[15]: | 898| 46|OBJT |LOCL |0 |4 |Int_yydefgoto
[16]: | 756| 142|OBJT |LOCL |0 |4 |Int_yydefact
[17]: | 674| 82|OBJT |LOCL |0 |4 |Int_yyr2
[18]: | 592| 82|OBJT |LOCL |0 |4 |Int_yyr1
[19]: | 364| 228|OBJT |LOCL |0 |4 |Int_yyrhs
[20]: | 282| 82|OBJT |LOCL |0 |4 |Int_yyprhs
[21]: | 0| 281|OBJT |LOCL |0 |4 |Int_yytranslate
[22]: | 4| 4|OBJT |GLOB |0 |COMMON |fmgr_pl_finfo
[23]: | 0| 0|NOTY |GLOB |0 |UNDEF |InsertOneNull
[24]: | 0| 0|NOTY |GLOB |0 |UNDEF |InsertOneValue
[25]: | 0| 0|NOTY |GLOB |0 |UNDEF |newoid
[26]: | 0| 0|NOTY |GLOB |0 |UNDEF |atol
[27]: | 0| 0|NOTY |GLOB |0 |UNDEF |DefineAttr
[28]: | 0| 0|NOTY |GLOB |0 |UNDEF |makeString
[29]: | 0| 0|NOTY |GLOB |0 |UNDEF |newNode
[30]: | 0| 0|NOTY |GLOB |0 |UNDEF |build_indices
[31]: | 0| 0|NOTY |GLOB |0 |UNDEF |DefineIndex
[32]: | 0| 0|NOTY |GLOB |0 |UNDEF |lappend
[33]: | 0| 0|NOTY |GLOB |0 |UNDEF |InsertOneTuple
[34]: | 0| 0|NOTY |GLOB |0 |UNDEF |err_out
[35]: | 0| 0|NOTY |GLOB |0 |UNDEF |elog
[36]: | 0| 0|NOTY |GLOB |0 |UNDEF |heap_create_with_catalog
[37]: | 0| 0|NOTY |GLOB |0 |UNDEF |heap_create
[38]: | 0| 0|NOTY |GLOB |0 |UNDEF |CreateTupleDesc
[39]: | 0| 0|NOTY |GLOB |0 |UNDEF |attrtypes
[40]: | 0| 0|NOTY |GLOB |0 |UNDEF |DebugMode
[41]: | 0| 0|NOTY |GLOB |0 |UNDEF |puts
[42]: | 0| 0|NOTY |GLOB |0 |UNDEF |reldesc
[43]: | 0| 0|NOTY |GLOB |0 |UNDEF |__flsbuf
[44]: | 0| 0|NOTY |GLOB |0 |UNDEF |numattr
[45]: | 0| 0|NOTY |GLOB |0 |UNDEF |closerel
[46]: | 0| 0|NOTY |GLOB |0 |UNDEF |fflush
[47]: | 0| 0|NOTY |GLOB |0 |UNDEF |__iob
[48]: | 0| 0|NOTY |GLOB |0 |UNDEF |printf
[49]: | 0| 0|NOTY |GLOB |0 |UNDEF |Quiet
[50]: | 0| 0|NOTY |GLOB |0 |UNDEF |CommitTransactionCommand
[51]: | 0| 0|NOTY |GLOB |0 |UNDEF |boot_openrel
[52]: | 0| 0|NOTY |GLOB |0 |UNDEF |LexIDStr
[53]: | 0| 0|NOTY |GLOB |0 |UNDEF |StartTransactionCommand
[54]: | 4| 4|OBJT |GLOB |0 |COMMON |Int_yylval
[55]: | 0| 0|NOTY |GLOB |0 |UNDEF |Int_yylex
[56]: | 0| 0|NOTY |GLOB |0 |UNDEF |alloca
[57]: | 0| 0|NOTY |GLOB |0 |UNDEF |Int_yyerror
[58]: | 4| 4|OBJT |GLOB |0 |COMMON |Int_yychar
[59]: | 4| 4|OBJT |GLOB |0 |COMMON |Int_yynerrs
[60]: | 48| 2368|FUNC |GLOB |0 |1 |Int_yyparse
[61]: | 0| 4|OBJT |GLOB |0 |2 |num_tuples_read

ld -r -o SUBSYS.o fmgrtab.o adt/SUBSYS.o cache/SUBSYS.o error/SUBSYS.o fmgr/SUBSYS.o hash/SUBSYS.o init/SUBSYS.o misc/SUBSYS.o mmgr/SUBSYS.o sort/SUBSYS.o time/SUBSYS.o
gmake[2]| 0| 0|SECT |LOCL |0 |1 |.text: Leaving directory `/usr/src/pgsql/postgresql-6.3.2/src/backend/utils'
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 -lgen -lcrypt -lld -lnsl -lsocket -ldl -lm -ltermcap -lcurses -lc89 -lc89 -Wl,-Bexport
Undefined first referenced
symbol in file
alloca bootstrap/SUBSYS.o
UX:ld: ERROR: postgres: fatal error: Symbol referencing errors. No output written to postgres
gmake[1]| 0| 0|FILE |LOCL |0 |ABS |bootparse.y: *** [postgres] Error 1
gmake[1]| 0| 0|FILE |LOCL |0 |ABS |bootparse.y: Leaving directory `/usr/src/pgsql/postgresql-6.3.2/src/backend'
gmake: *** [all] Error 2

----
North Richmond Community Mental Health Center

Thomas Good Information Systems Coordinator
E-Mail: tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056

Empowered by PostgreSQL 6.3.2

On Wed, 28 Apr 1999, Bruce Momjian wrote:

On Wed, 28 Apr 1999, Bruce Momjian wrote:

It is this line:

[56] | 0| 0|NOTY |GLOB |0 |UNDEF |alloca

Your bison is outputting code that can not be resolved by the libraries
you supplied. Try doing 'nm' in /usr/lib, and see if you can find a
reference to alloca that does not have "UNDEF" next to it.

Hi. Negative...not in /usr/lib, /opt/lib or /lib *but* I found
one entry in my Berkeley libraries (/usr/ucblib):

Symbols from libucb.a[alloca.o]:
[1]: | 0| 0|FILE |LOCL |0 |ABS |alloca.s
[4]: | 0| 0|NOTY |GLOB |0 |1 |alloca

----
North Richmond Community Mental Health Center
---
Thomas Good tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056
Powered By: Slackware 3.6 PostgreSQL 6.3.2
---
/* Die Wahrheit Ist Irgendwo Da Draussen... */

----
North Richmond Community Mental Health Center

Thomas Good Information Systems Coordinator
E-Mail: tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056

Empowered by PostgreSQL 6.3.2

On Wed, 28 Apr 1999, Bruce Momjian wrote:

or Linux) gmake barfs with:
Undefined symbol alloca in file bootstrap/SUBSYS.o

The alloca calls are coming from the code generated by bison. Strange
it would do that on Unixware. You would think bison would know if
alloca was available, and only use it if it was. If you use 'nm' you
will see the unresolved call in bootparse.c, no?

Bruce - I am not sure what I am looking for...so here is the stdout from
running nm (tail make.log follows the nm output).

Thanks for taking the time, I know you're rather busy.

It is this line:

[56]: | 0| 0|NOTY |GLOB |0 |UNDEF |alloca

Your bison is outputting code that can not be resolved by the libraries
you supplied. Try doing 'nm' in /usr/lib, and see if you can find a
reference to alloca that does not have "UNDEF" next to it.

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

On Wed, 28 Apr 1999, Thomas Good wrote:

It is this line:

[56] | 0| 0|NOTY |GLOB |0 |UNDEF |alloca

Your bison is outputting code that can not be resolved by the libraries
you supplied. Try doing 'nm' in /usr/lib, and see if you can find a
reference to alloca that does not have "UNDEF" next to it.

Hi. Negative...not in /usr/lib, /opt/lib or /lib *but* I found
one entry in my Berkeley libraries (/usr/ucblib):

Symbols from libucb.a[alloca.o]:
[1] | 0| 0|FILE |LOCL |0 |ABS |alloca.s
[4] | 0| 0|NOTY |GLOB |0 |1 |alloca

Bruce - I see the calls in /opt/lib/bison.simple to alloca...
can I make a careful incision anywhere? ;-)

----
North Richmond Community Mental Health Center

Thomas Good Information Systems Coordinator
E-Mail: tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056

Empowered by PostgreSQL 6.3.2

On Wed, 28 Apr 1999, Bruce Momjian wrote:

Symbols from libucb.a[alloca.o]:
[1] | 0| 0|FILE |LOCL |0 |ABS |alloca.s
[4] | 0| 0|NOTY |GLOB |0 |1 |alloca

Bing. Looks like bison-programs need -lucb as a compiler option. Try
that and see.

Bruce -

gmake all

produces seemingly benign output:

gmake -C lextest all
gmake[1]: Entering directory `/usr/src/pgsql/postgresql-6.3.2/src/lextest'
gmake[1]: Leaving directory `/usr/src/pgsql/postgresql-6.3.2/src/lextest'

But of course, make fails...so trying to force the issue with:

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/SUBSYS.o
storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../utils/version.o
-lgen -lcrypt -lld -lnsl -lsocket -ldl -lm -ltermcap -lcurses
-lc89 -lc89 -Wl,-Bexport -lucb

produces:
UX:ld: ERROR: fatal error: library not found: -lucb

I've tried different placement of the flag in the cc cmd but the
result is the same. Ouch. I've re-read the ld man page but see
no reference to calling the beserkely libs. At a loss (again).

Tom
----
North Richmond Community Mental Health Center

Thomas Good Information Systems Coordinator
E-Mail: tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056

Empowered by PostgreSQL 6.3.2

On Wed, 28 Apr 1999, Bruce Momjian wrote:

On Wed, 28 Apr 1999, Bruce Momjian wrote:

It is this line:

[56] | 0| 0|NOTY |GLOB |0 |UNDEF |alloca

Your bison is outputting code that can not be resolved by the libraries
you supplied. Try doing 'nm' in /usr/lib, and see if you can find a
reference to alloca that does not have "UNDEF" next to it.

Hi. Negative...not in /usr/lib, /opt/lib or /lib *but* I found
one entry in my Berkeley libraries (/usr/ucblib):

Symbols from libucb.a[alloca.o]:
[1] | 0| 0|FILE |LOCL |0 |ABS |alloca.s
[4] | 0| 0|NOTY |GLOB |0 |1 |alloca

Bing. Looks like bison-programs need -lucb as a compiler option. Try
that and see.

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

On Wed, 28 Apr 1999, Thomas Good wrote:

It is this line:

[56] | 0| 0|NOTY |GLOB |0 |UNDEF |alloca

Your bison is outputting code that can not be resolved by the libraries
you supplied. Try doing 'nm' in /usr/lib, and see if you can find a
reference to alloca that does not have "UNDEF" next to it.

Hi. Negative...not in /usr/lib, /opt/lib or /lib *but* I found
one entry in my Berkeley libraries (/usr/ucblib):

Symbols from libucb.a[alloca.o]:
[1] | 0| 0|FILE |LOCL |0 |ABS |alloca.s
[4] | 0| 0|NOTY |GLOB |0 |1 |alloca

Bruce - I see the calls in /opt/lib/bison.simple to alloca...
can I make a careful incision anywhere? ;-)

Usually configure of bison checks for alloca and makes the proper
compile checks. My guess is that either bison automatically uses -lucb
on its configure checks, or you got a bison precompile binary where
someone used -lucb. I don't think bison requires it, but your's does.
Alloca can not easily be simulated.

---------------------------------------------------------------------------

NAME
alloca - memory allocator

SYNOPSIS
#include <stdlib.h>

void *
alloca(size_t size);

DESCRIPTION
The alloca() function allocates size bytes of space in the stack
frame of
the caller. This temporary space is automatically freed on return.

RETURN VALUES
The alloca() function returns a pointer to the beginning of the
allocated
space. If the allocation failed, a NULL pointer is returned.

SEE ALSO
brk(2), pagesize(2) calloc(3), malloc(3), realloc(3),

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

Bruce - by commenting ecpg out of the interfaces Makefile I got
all of Postgres to compile and have successfully run initdb...

As soon as I can resolve the IpcMemory errors I hope to have this
thing going.

Thanks for all of your help,
Tom
----
North Richmond Community Mental Health Center

Thomas Good Information Systems Coordinator
E-Mail: tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056

Empowered by PostgreSQL 6.3.2

After commented the line with "ecpg" (there is only one such line)
from the GNUmake file, the make all didn't go very far but ended with
the following message:

make -C utils all
make[1]: Entering directory `/home/humphrey/postgresql-6.4.2/src/utils'
cc -I../include -I../backend -c version.c
UX:acomp: ERROR: "/usr/include/strings.h", line 20: identifier redeclared:
strca
secmp
UX:acomp: ERROR: "/usr/include/stdlib.h", line 169: identifier redeclared:
srand
om
make[1]: *** [version.o] Error 1
make[1]: Leaving directory `/home/humphrey/postgresql-6.4.2/src/utils'
make: *** [all] Error 2

I used 6.4.2 on UnixWare 2.1.3.

Jun

----------

On Thu, 29 Apr 1999, Jun Zhang wrote:

After commented the line with "ecpg" (there is only one such line)
from the GNUmake file, the make all didn't go very far but ended with
the following message:

I'm sorry but I'm confused...you did *not* succeed in compiling?
I eventually did succeed and am now looking at increasing semaphores
and shared memory so that the d*mn IpcMemory errors take a hike.

I am no fan of UnixWare. It was a real dance to get UUCP over TCP
working - and sendmail was also a week of fun. It is hard for me to
believe that this was once ATT src code. Of course, ATT never would
have released it in this state...that was done by Novell with an
encore by SCO.

I plan to get a pint (or three) and start on my kernel rebuild later.
(Expletive deleted) I thought BSD was the unix for kernel rebuilds
(based on the philosophy that the user should be able to build something
specially tailored to his/her needs). System V kernels are supposed
to handle *any* eventuality. Hah...

In the event I'm reading you correctly and your compilation failed:

Once I rm'd ecpg from the Makefile list in ./interfaces I was able
to compile and then install. Next I added /usr/local/pgsql/lib
to LD_LIBRARY_PATH and I ran initdb. Now I need to get the postmaster
fired up and that means more shared memory.

BTW, this is PG 6.3.2 on UW 2.1.2...

Good luck with your situation. If I can do anything to help (send my
log notes, whatever) let me know. I'd be willing to send binaries
if you like.

Cheers,
Tom

make -C utils all
make[1]: Entering directory `/home/humphrey/postgresql-6.4.2/src/utils'
cc -I../include -I../backend -c version.c
UX:acomp: ERROR: "/usr/include/strings.h", line 20: identifier redeclared:
strca
secmp
UX:acomp: ERROR: "/usr/include/stdlib.h", line 169: identifier redeclared:
srand
om
make[1]: *** [version.o] Error 1
make[1]: Leaving directory `/home/humphrey/postgresql-6.4.2/src/utils'
make: *** [all] Error 2

I used 6.4.2 on UnixWare 2.1.3.

Jun

----------

From: Thomas Good <tomg@admin.nrnet.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
Cc: pgsql-general@postgreSQL.org; scrappy@hub.org
Subject: Re: [GENERAL] UnixWare chokes --- Resolution
Date: Thursday, April 29, 1999 8:55 AM

Bruce - by commenting ecpg out of the interfaces Makefile I got
all of Postgres to compile and have successfully run initdb...

As soon as I can resolve the IpcMemory errors I hope to have this
thing going.

Thanks for all of your help,
Tom
----
North Richmond Community Mental Health Center

Thomas Good Information Systems Coordinator
E-Mail: tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056

Empowered by PostgreSQL 6.3.2

----
North Richmond Community Mental Health Center

Thomas Good Information Systems Coordinator
E-Mail: tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056

Empowered by PostgreSQL 6.3.2