From: | Bruce Hartzler <bruceh(at)mail(dot)utexas(dot)edu> |
---|---|
To: | darwin-development(at)public(dot)lists(dot)apple(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | howto: install posgresql on darwin/osxpb |
Date: | 2000-10-22 09:25:38 |
Message-ID: | E13nHNR-0003Xu-00@smtp03.mrf.mail.rcn.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
<flushleft><fontfamily><param>Helvetica</param><x-tabstops><param>72L;144L;216L;288L;360L;0L;</param>Here's a patch to get postgresql up and running (I've only tested it on PB w/ dev tools but it should work on Darwin as well). It's very rough but I thought I'd put it up for those of you who are interested. If anyone has suggestions or help for some of the remaining issues listed below, please email me. Thanks.
http://www.gerga.com/pg_darwin_patch.tar.gz
to install:
wget ftp://ftp.postgresql.org/pub/v7.0.2/postgresql-7.0.2.tar.gz
wget http://www.gerga.com/pg_darwin_patch.tar.gz
tar xzvf postgresql-7.0.2.tar.gz
tar xzvf pg_darwin_patch.tar.gz
cd postgresql-7.0.2
patch -p1 << ../pg_darwin_patch
(WARNING! You need to put a symlink in your /usr/include/sys dir to sem.h. OSXPB doesn't have the sysv semaphore implementation included but it seems to be in the newer kernels -- so check before you clobber something you might already have. I'm currently just using the qnx semaphore port but this should probably be removed when Apple's semaphore implementation arrives.)
ln -s `pwd`/src/backend/port/darwin/sem.h /usr/include/sys/sem.h
cd src
./configure --without-CXX -with-perl
(c++ lib needs to be hacked; perl seems to work; I haven't really tried other options yet.)
make
make install
these default paths help:
export DYLD_LIBRARY_PATH="${DYLD_LIBRARY_PATH}:/usr/local/pgsql/lib"
export PGDATA="/usr/local/pgsql/data"
export PGLIB="/usr/local/pgsql/lib"
read postgresql-7.0.2/INSTALL for setting up the postmaster and getting things going.
(initdb /usr/local/pgsql/data; postmaster)
for the regression tests:
cd postgres-7.0.2/src/tests/regress
make
make runtest
(int2 & int4 will "fail" because of different error messages)
(geometry "fails" because 0 != -0 for some reason)
some issues/problems:
- if you try to load a badly made dynamic library, you will get an error like:
dyld: /usr/local/pgsql/bin/./postmaster Undefined symbols:
dyld_stub_binding_helper
Server process (pid 8932) exited with status 17152 at Sun Oct 22 00:41:22 2000
Terminating any active server processes...
Server processes were terminated at Sun Oct 22 00:41:22 2000
Reinitializing shared memory and semaphores
Need to fix/make the error routine in src/backend/port/dynloader/darwin.c?
-running the regression tests more than once seems to corrupt the database. it can't be dropped or created the second time. I I haven't found a way to get rid of it beside re-initdb-ing the data directory which isn't a very useful solution at all. ideas/suggestions?
- there may be semaphore/shared memory leaking going on. the routines are a bit of a cludge and the postgres ipcclean utility needs ipcs. is there an osx equivalent?
- when compiled with any -O, the following regression tests fail:
oidjoins .. failed
type_sanity .. failed
opr_sanity .. failed
<x-tabstops><param>28L;56L;84L;112L;140L;168L;196L;224L;252L;280L;308L;336L;</param> </x-tabstops></x-tabstops></fontfamily></flushleft>
>From pgsql-hackers-owner(at)hub(dot)org Sun Oct 22 12:18:54 2000
Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
by hub.org (8.10.1/8.11.0) with ESMTP id e9MGInJ54782
for <pgsql-hackers(at)postgresql(dot)org>; Sun, 22 Oct 2000 12:18:50 -0400 (EDT)
(envelope-from tgl(at)sss(dot)pgh(dot)pa(dot)us)
Received: from sss2.sss.pgh.pa.us (tgl(at)localhost [127.0.0.1])
by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id e9MGIl503604;
Sun, 22 Oct 2000 12:18:47 -0400 (EDT)
To: bruceh(at)mail(dot)utexas(dot)edu
cc: darwin-development(at)public(dot)lists(dot)apple(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: howto: install posgresql on darwin/osxpb
In-reply-to: <E13nHNR-0003Xu-00(at)smtp03(dot)mrf(dot)mail(dot)rcn(dot)net>
References: <E13nHNR-0003Xu-00(at)smtp03(dot)mrf(dot)mail(dot)rcn(dot)net>
Comments: In-reply-to Bruce Hartzler <bruceh(at)mail(dot)utexas(dot)edu>
message dated "Sun, 22 Oct 2000 05:25:38 -0400"
Date: Sun, 22 Oct 2000 12:18:46 -0400
Message-ID: <3601(dot)972231526(at)sss(dot)pgh(dot)pa(dot)us>
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
X-Archive-Number: 200010/859
X-Sequence-Number: 7889
Bruce Hartzler <bruceh(at)mail(dot)utexas(dot)edu> writes:
> (int2 & int4 will "fail" because of different error messages)
> (geometry "fails" because 0 != -0 for some reason)
See the documentation about platform-specific regress test comparison
files. You'll need to add entries to regress/resultmap. There may well
be existing comparison files that work for you, else add another one.
> - when compiled with any -O, the following regression tests fail:
> oidjoins .. failed
> type_sanity .. failed
> opr_sanity .. failed
Probably the known fmgr portability problems for PPC. Postgres has
never worked with -O on any PPC platform (at least not with gcc).
It's actually not so interesting to be porting 7.0.* at this point ---
what you really should be working on is pgsql's current development
sources, with the hope that you can contribute patches to make 7.1
work out-of-the-box. The fmgr issues are fixed now on PPC (I've run
regression tests -O2 on LinuxPPC with no problems), and Peter Eisentraut
has made huge strides toward bringing our configure/build system into
line with standard GNU & autoconf practice. So in theory the port
should be less painful than it was for 7.0.*.
You can pull current sources from our CVS server, or there's a nightly
snapshot tarfile. Note you should test on a known-supported platform
(LinuxPPC is now in that class, if that's convenient for you) to make
sure you got a working snapshot and not momentary devel breakage :-(
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
unknown_filename | text/enriched | 5.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-10-22 12:26:12 | Re: foreign key introduces unnecessary locking ? |
Previous Message | Tatsuo Ishii | 2000-10-22 09:12:12 | Re: incompatible changes of PQsetdbLogin() |