Thread: add darwin/osxpb support to cvs
this patch and tar archive will add support for the darwin/osxpb to the current cvs tree. a couple things to note: - unpack the tar archive in pgsql/ - the config.guess and config.sub files have been updated by apple to support their new os. i don't think these changes havebeen folded back in to the main archive yet (at least they aren't in the pgsql cvs yet). these need to be copied overfrom /usr/libexec/config.* in order to obtain the correct os (e.g. powerpc-apple-darwin1.2 on PB). - the diff only patches configure.in so autoconf needs to be rerun - the situation with darwin's implementation of sysv semaphores is in progress at the moment (the shm/ipc support *is* thereand seems to work fine). so this patch uses HAVE_SYS_SEM_H to conditionally build the src/backend/port/darwin semaphorecode (borrowed from qnx4). 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 sysvsem built into the kernel. - 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 compileat all on darwin so i just added a version that does work on darwin under DARWIN_OS. it's potentially a bit confusingand s_lock.c should probably be changed to include a better conditional. bruce
Attachment
Do you actually *need* -O0 on darwin with current sources?
Or is that a leftover from 7.0.* ? AFAIK -O2 should work on PPC.
regards, tom lane
On Monday, October 23, 2000, at 12:43 PM, Tom Lane wrote: > Do you actually *need* -O0 on darwin with current sources? > Or is that a leftover from 7.0.* ? AFAIK -O2 should work on PPC. > > regards, tom lane > > Yes, that's correct. That can be bumped up to -O2 now and it works fine (and remove the -g flag as well). It does createa very small difference in the geometry floating point tests though. I checked with the other platform results anddidn't find any match so I might just have to generate a specific file. Another problem I discovered happens when you compile --with-perl. It compiles libpq.a ok, runs ranlib on it, installs itinto /usr/local/pgsql/lib ok, but then when it tries to build the Perl module and link against it, it generates a "runranlib on libpq" error. I don't know where exactly it's messing up but simply adding an extra '$(RANLIB) $(DESTDIR)$(libdir)/lib$(NAME).a'right after '$(INSTALL_DATA) $< $(DESTDIR)$(libdir)/lib$(NAME).a' in Makefile.shlib seemsto hack/fix the problem. I have to look closer at the Perl build section I guess. That assembly code in s_lock.c also really needs to be changed to reflect a possible build on a i386 darwin system. Thereis already a __powerpc__ label in there and Apple is recommending that we only use __ppc__ or __Apple__ now since theyplan on phasing the other labels out at some point in the future. How about just using both of these instead? The theDARWIN_OS flag can be dumped and the i386 code can be tagged as __Apple__ and __i386__. thanks for you help, bruce Here's the output from ccsym: __GNUC__=2 __GNUC_MINOR__=95 __ppc__ __NATURAL_ALIGNMENT__ __MACH__ __BIG_ENDIAN__ __APPLE__ __ppc__ __NATURAL_ALIGNMENT__ __MACH__ __BIG_ENDIAN__ __APPLE__ __STDC__ __APPLE_CC__=912 __DYNAMIC__
I'll take this and integrate it. Please, nobody commit this right now, I'm messing with things... Bruce Hartzler writes: > this patch and tar archive will add support for the darwin/osxpb to the current cvs tree. > > a couple things to note: > > - unpack the tar archive in pgsql/ > > - the config.guess and config.sub files have been updated by apple to support their new os. i don't think these changeshave been folded back in to the main archive yet (at least they aren't in the pgsql cvs yet). these need to be copiedover from /usr/libexec/config.* in order to obtain the correct os (e.g. powerpc-apple-darwin1.2 on PB). > > - the diff only patches configure.in so autoconf needs to be rerun > > - 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 the src/backend/port/darwin semaphorecode (borrowed from qnx4). 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 sysvsem built into the kernel. > > - i'm a bit confused over the __powerpc__ tas function in s_lock.c (there i assume for the ppc-linux port). it doesn'tcompile at all on darwin so i just added a version that does work on darwin under DARWIN_OS. it's potentially a bitconfusing and s_lock.c should probably be changed to include a better conditional. > > bruce > > > -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
[ folks in Cc: were also interested in Darwin/MacOS X support ] Bruce Hartzler writes: > this patch and tar archive will add support for the darwin/osxpb to the current cvs tree. Greetings. I installed parts of your patch, which should at least get you, or other interested people going. Open issues: * Dynamic loader code that's under a BSD license. I've just installed dummy files for now. * It was reported that the assembler doesn't like the__powerpc__ code in backend/storage/buffer/s_lock.h. Your code looks essentially the same, so it seems to be a syntax discrepancy between the GNU assembler and whatever your system uses. Perhaps we could check if the altered code works on other systems as well before we install duplicates? (The GNU assembler ought to be pretty flexible.) * Semaphore support reportedly does exist in new kernels, so I don't think we need to add that to the tree. Maybe a separate patch for older kernels is in order. Besides that, try to build all the optional parts (C++, Tcl, ODBC, ...) as well. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
>Greetings.
>
>I installed parts of your patch, which should at least get you, or other
>interested people going.
>Open issues:
>
>* Dynamic loader code that's under a BSD license. I've just installed
>dummy files for now.
Thanks Peter,
I heard back from Fred about the dynamic loader code. He gave the ok
to use it outside the Apache license (see below).
>* It was reported that the assembler doesn't like the__powerpc__ code in
>backend/storage/buffer/s_lock.h. Your code looks essentially the same, so
>it seems to be a syntax discrepancy between the GNU assembler and whatever
>your system uses. Perhaps we could check if the altered code works on
>other systems as well before we install duplicates? (The GNU assembler
>ought to be pretty flexible.)
You are probably right. Apple's gcc-based compiler was split off from
the main tree a while back when they were adding a bunch of
NEXT-based objective-c compiling routines to it. I know people have
been trying to merge the changes back into the main gcc tree (and new
gcc changes into Apple's) but I don't know how long this process it
going to go on for. For now though, it won't compile the other PPC
code already in there.
>* Semaphore support reportedly does exist in new kernels, so I don't think
>we need to add that to the tree. Maybe a separate patch for older kernels
>is in order.
This sound fine with me. The C++ stuff worked ok with the cvs tree.
The Tcl stuff is on the way and might be working now (it's on the
Darwin cvs server). I'll look into ODBC.
Thanks for your help,
Bruce
-------------------------------------------
Delivered-To: bruceh@mail.utexas.edu
Date: Wed, 25 Oct 2000 12:24:07 +0000
Reply-To: wsanchez@apple.com
From: Wilfredo Sanchez <wsanchez@apple.com>
To: Bruce Hartzler <bruceh@mail.utexas.edu>
Mime-Version: 1.0 (Apple Message framework v337)
Subject: Re: dynloader code in Apache
Status: R
> I was wondering if you had released your dynloader code under any
> other licenses besides Apache's? I've brought it over in order to get
> Postgresql running on Darwin but I think the people managing the
> Postgresql code are a bit uneasy about using it under Apache's
> advertising license. Anything you might suggest would be most helpful.
The code is pretty simple to reproduce from just looking at the headers.
You needn't worry about the license. Pretend I sent it to you as a patch.
-Fred
Wilfredo Sánchez, wsanchez@apple.com
Open Source Engineering Lead
Apple Computer, Inc., Core Operating System Group
1 Infinite Loop, Cupertino, CA 94086, 408.974-5174