Thread: Re: [PATCHES] add darwin/osxpb support to cvs

Re: [PATCHES] add darwin/osxpb support to cvs

From
Peter Eisentraut
Date:
Bruce Hartzler writes:

> this patch and tar archive will add support for the darwin/osxpb to the current cvs tree.

Next time you can make your patch with "diff -crN" so that you don't have
to create a separate tarball.

> - the config.guess and config.sub files have been updated by apple to
> support their new os. i don't think these changes have been folded
> back in to the main archive yet

I installed the latest ones from GNU which claim to support it according
to the ChangeLog.

> - the situation with darwin's implementation of sysv semaphores is in
> progress at the moment (the shm/ipc support *is* there and seems to
> work fine). so this patch uses HAVE_SYS_SEM_H to conditionally build

HAVE_SYS_SEM_H is a preprocessor symbol, not a makefile variable.

> the src/backend/port/darwin semaphore code (borrowed from qnx4).

If you could arrange it, could you use the same files as QNX, perhaps with
an #ifdef here or there

> I've followed the BeOS example of including the necessary sem.h
> declarations in src/include/port/darwin.h. this is rather messy at the
> moment and can be dumped once apple releases a version of PB with sysv
> sem built into the kernel.

The include/port/beos.h isn't really a shining example of how to do this.  
This file is include *everywhere*, but we don't want to know about
semaphores everywhere.  I'd prefer it if you use the QNX approach and
symlink sem.h into an include directory (e.g., /usr/local/include/sys),
since it's only temporary anyway.

Also, overriding configure results (à la #undef HAVE_UNION_SEMUN) isn't
cool.

I'm also somewhat concerned about the dynloader.c because it's under the
Apache license which has a funny advertisement clause.  Comments from
someone?

> - i'm a bit confused over the __powerpc__ tas function in s_lock.c
> (there i assume for the ppc-linux port). it doesn't compile at all on
> darwin so i just added a version that does work on darwin under
> DARWIN_OS. it's potentially a bit confusing and s_lock.c should
> probably be changed to include a better conditional.

The compiler probably predefines something like __darwin__, which you
should use.  You can find out with 

touch foo.h
cc -E -dM foo.h
rm foo.h

And finally, what's up with this:

CFLAGS='-O0 -g -traditional-cpp'

?  What's wrong with the "modern-cpp"?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: [PATCHES] add darwin/osxpb support to cvs

From
Bruce Hartzler
Date:
>Next time you can make your patch with "diff -crN" so that you don't have
>to create a separate tarball.

No problem. I tried just doing a diff with cvs but wasn't able to get 
the -N option to work. This is the first time I've ever tried 
patching unix software so I'm sorry if it's a bit messy. Thanks for 
you help in getting it right.


>  > - the config.guess and config.sub files have been updated by apple to
>>  support their new os. i don't think these changes have been folded
>>  back in to the main archive yet
>
>I installed the latest ones from GNU which claim to support it according
>to the ChangeLog.

I'll try checking out the new versions and see if they work. I can 
send you a diff with the ones I have here if you want to see the 
additions Apple made.


>  > I've followed the BeOS example of including the necessary sem.h
>>  declarations in src/include/port/darwin.h. this is rather messy at the
>>  moment and can be dumped once apple releases a version of PB with sysv
>>  sem built into the kernel.
>
>The include/port/beos.h isn't really a shining example of how to do this. 
>This file is include *everywhere*, but we don't want to know about
>semaphores everywhere.  I'd prefer it if you use the QNX approach and
>symlink sem.h into an include directory (e.g., /usr/local/include/sys),
>since it's only temporary anyway.

I agree it's rather messy. I originally had just used the sym link in 
/usr/local/include, but as I said, some of the newer Darwin kernels 
have the sysv sem.h file already there and I was worried about people 
overwriting it. If you think it's fair to put this responsibility on 
the end user, I'm ok with that. I just thought it might be nice to 
check and see if the semaphore implementation was already there, and 
if not, build the necessary parts. I'll switch it back to the way it 
was.

>I'm also somewhat concerned about the dynloader.c because it's under the
>Apache license which has a funny advertisement clause.  Comments from
>someone?

I wondering about this too. I'll try emailing Wilfredo Sanchez and 
see if I can get the code outside the Apache license. This would 
probably be easiest.


>The compiler probably predefines something like __darwin__, which you
>should use.  You can find out with

It doesn't actually provide __darwin__ but as I mentioned in a 
previous post, Apple is suggesting people use __APPLE__ combined with 
__ppc__ or __i386__ for the different darwin builds. The section in 
s_lock.c should probably be changed to reflect this instead of using 
DARWIN_OS.


>And finally, what's up with this:
>
>CFLAGS='-O0 -g -traditional-cpp'
>
>?  What's wrong with the "modern-cpp"?

Apple's "modern-cpp" called cpp-precomp uses some strange parsing 
that breaks on several files in the postgresql build. They are still 
working on it apparently and are suggesting people simply use the 
-traditional-cpp flag when this happens instead of trying to update 
the files.

Thanks again for all your comments and suggestions.

Bruce