At 3:36 PM 10/10/97, Colin Wood wrote:
>Henry B. Hotz wrote:
>>
>> 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?
....
>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.

The relevant file ...include/storage/s_lock.h has an appropriate asm
routine already, but it only gets used #if defined(sun3).  What is the
"official" test for a 68000-based NetBSD variant?  __NetBSD__ && __m68k?
__NetBSD__ && __m68k__?  Or should I use __mc680[02]0[__] variants?  Or
does it even matter?

In general s_lock.h looks like a bit of a mess with all sorts of strange
variations of configuration tests.  I'll take the word of the comments that
there is a performance advantage to busy waiting instead of semaphores.
The routines do not seem to be OS dependent.  The configuration tests are
very much so, more so than they need to be IMHO.

There seem to usable assembly routines for i386, sparc, m68k, PPC, and
alpha.  (Sometimes more than one!)  I wonder how hard it would be to fix
things so the various NetBSD variants would get the right asm() routines or
else default back to semaphores.

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

I'll let you know when I get that far, but I'm hoping to get the real
Postgres source patched properly so the other NetBSD ports have a chance.
If there is a bug in -current then I hope it gets fixed before I get there.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu