Henry B. Hotz wrote:
> 
> This is a touch off-topic, but I just tried building Postgres and it failed
> as follows:
> 
> >gmake[2]: Leaving directory `/usr/local/dist/postgresql-6.2/src/backend/utils'
> >gcc -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o
> >commands/SUB
> >SYS.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/SUBS
> >YS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o
> >../utils/ver
> >sion.o -L/usr/local/lib -lcrypt -lcompat -lm -ltermcap -lcurses
> >access/SUBSYS.o: warning: mktemp() possibly used unsafely, consider using
> >mkstem
> >p()
> >storage/SUBSYS.o: Undefined symbol `_S_INIT_LOCK' referenced from text segment
> >storage/SUBSYS.o: Undefined symbol `_S_UNLOCK' referenced from text segment
[snip]
> >storage/SUBSYS.o: More undefined symbol _S_UNLOCK refs follow
> >gmake[1]: *** [postgres] Error 1
> >gmake[1]: Leaving directory `/usr/local/dist/postgresql-6.2/src/backend'
> >gmake: *** [all] Error 2
> 
> So, I have two questions:  1) what gives with the mktemp() stuff, is that
> discussed over on the generic users list?  I got the same error building
> GNU make.

Really?  I think that I remember getting GNUmake to compile cleanly after
running configure...

> 2) The undefined symbol stuff looks like a missing library, but I don't
> know which one.  Could the configure be picking up the wrong locking
> mechanism for this OS?
> 
> I'm running -current of Sept 27.  Postgres 6.2.

The problem is that m68k either lacks a "test and set" instruction, or
else the glue code to work this instruction into Postgres is missing for
m68k.  The NetBSD-specific stuff for PostgreSQL is mainly
NetBSD/i386-specific :-(  I found that making a change to one of the
header files fixed the problem.  The change basically involved making the
locking functions not use a "test and set" instruction implementation if
the NetBSD platform is m68k-based.  I'm fairly sure that it compiled ok at
this point.

However, there is a rather annoying problem:  you cannot initialize the
test database as described in the install docs.  Basically, the
initialization goes fine until a specific error condition occurs which
results in a call to longjmp(2?) which then fails with:

longjmp botch!

or whatever the standard error message is. :-(  I've seen a post about
this problem from someone using NetBSD/sun3 as well.  I think that there
is most likely a bug in either the m68k in-kernel setjmp/longjmp code, or
else in the libc part of it.  I haven't downloaded the libc sources, so I
haven't been able to track it down any farther (and I don't know enough
about m68k assembly to really know what's going on in some of the hairier
spots there, either).  If you figure anything more out, please let me
know.

Later.

-- 
Colin Wood                                 cwood@ichips.intel.com
Component Design Engineer - MD6                 Intel Corporation
-----------------------------------------------------------------
I speak only on my own behalf, not for my employer.