Skip site navigation (1) Skip section navigation (2)

Re: darwin pgsql patches

From: Peter Bierman <bierman(at)apple(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: darwin pgsql patches
Date: 2000-12-01 02:24:32
Message-ID: v03130314b64cb73aa755@[] (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
At 5:30 PM +0100 11/29/00, Peter Eisentraut wrote:
>Peter Bierman writes:
>> Here are patches to CVS top of tree that allow darwin to completely
>> build and install. Unfortunately, the sem...() shim does not function
>> correctly yet, so it's not stable enough to use.
>We've been through this before.  Newer Darwin kernels have semaphore
>support, which means that you'll at least have to compensate for that.  I
>believe we agreed that semaphore support for older kernels would be
>available as a patch.

I just talked to the kernel engineer, and semctl & friends will not be in darwin anytime soon.

The current Darwin kernel supports the sem_* functions, but not sem_init and sem_destroy (unnamed BSD semaphores). sem_open and sem_close work though. I plan to change the qnx shim code to use named semaphores, and with luck, we'll be off to the races. ;-)

I still don't quite know what to do about:

>> +#if defined(darwin)
>> +#include "../backend/port/darwin/sem.h"
>> +#endif
>This doesn't work.  There's no guarantee that the source tree is the same
>as the build tree.

I'm guessing qnx4 doesn't have this problem because they have a <sys/sem.h>, just no implementation.

I could put the contents in os.h, though that feels wrong.
I could add a CFLAGS+=-Isrc/backend/port/darwin/ either to the affected file's parent directory makefiles, or in template/darwin.




"4 out of 5 people with the wrong hardware want to run Mac OS X because..."

In response to

pgsql-patches by date

Next:From: Thomas LockhartDate: 2000-12-01 05:50:19
Subject: Re: darwin pgsql patches
Previous:From: Peter BiermanDate: 2000-11-30 21:21:30
Subject: Re: darwin pgsql patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group