Re: [GENERAL] postgres user account on OSX

2008-10-13 Thread Darren Weber
Hi Shane,

I'm trying to untangle some postgresql issues on OSX.  I'm now using a
macport installation for postgresql 8.3.4 and I'm using my own custom
Portfile to configure the installation (hardly changed from the main
Portfile, really).  Anyhow, the macport install creates a lauchdeamon config
that uses this startup call below.  When I test it directly, it's failing:

sudo su postgres -c /opt/local/lib/postgresql83/bin/pg_ctl -D
${POSTGRESQL83DATA:=/opt/local/var/db/postgresql83/defaultdb} start -w -l
/opt/local/var/log/postgresql83/postgres.log -o \-i -l\

waiting for server to start...2008-10-13 19:50:21.734 pg_ctl[43992:617]
CFPreferences: user home directory at /Library/PostgreSQL/8.3 is
unavailable. User domains will be volatile.
could not start
server

Have you seen anything like this before?  I have no idea what this means:
CFPreferences: user home directory at /Library/PostgreSQL/8.3 is
unavailable
It looks like a hangover from using a binary installer and I have no idea
how to get rid of that CFPreference.

Any tips much appreciated ;-)

Thanks, Darren



On Fri, Sep 12, 2008 at 8:52 AM, Shane Ambler [EMAIL PROTECTED] wrote:

 Darren Weber wrote:

  If you want a GUI to alter the home location of the existing user
 account run NetInfo Manager which is in /Applications/Utilities



 I have OSX Server.  This user account doesn't appear in the usual System
 Preferences  Accounts.  I did find it eventually under Applications 
 Server  Workgroup Manager, when I selected a local domain to administer.


 That would be a 10.5 machine.

 Seems Apple has dropped netinfo manager in 10.5 and replacing it with
 Directory and Directory Utility. (Data storage has changed too)

 Workgroup Manager is a OSX Server app that isn't a standard part of the
 client installs (but can be added by installing the server admin tools)
 and (pretty sure) it will only connect to an OSX Server to administer it
 - not useful for adjusting a client machine.
 You could call it a more user friendly form of netinfo manager (edits
 the same data)



 System Preferences  Accounts will only list accounts normally created
 within the Accounts Tab (I believe the criteria is userid's  500) which
 makes it easy for the novice user as they don't get to see all the
 system accounts like mailman, nobody, postmaster and so on, just the
 ones they have manually created.


 --

 Shane Ambler
 pgSQL (at) Sheeky (dot) Biz

 Get Sheeky @ http://Sheeky.Biz



[GENERAL] Has anyone built pgbash-7.3 against postgreSQL-8.3?

2008-09-30 Thread Darren Weber
I'm curious about pgbash.  I've taken a look at the website here:
http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html

According to the history on the main home page, the pgbash package was
last updated in 2003, ie:
2003.02.11 : pgbash-7.3 released (for PostgreSQL-7.3 and bash-2.05a).

I've made a start to build that package against postgresql-8.3 (on
macports).  The build failed with:

cc -O2 -I/opt/local/include/postgresql83  -c exec_sql_main.c
exec_sql_main.c:130: error: static declaration of 'sqlca' follows
non-static declaration
sqlca.h:44: error: previous declaration of 'sqlca' was here
make[1]: *** [exec_sql_main.o] Error 1
make: *** [../exec_sql/exec_sql_init.o] Error 1

It would be nice to debug this, if anyone can help?

I wonder about the general status of pgbash among the postgres
community - is it useful and is it still used?  Perhaps something else
replaced it and the development work stopped in 2003 in favor of
something else?

Thanks, Darren

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] macport for libpqxx

2008-09-20 Thread Darren Weber
http://pqxx.org/development/libpqxx/

I'm in the process of creating a macport for libpqxx.  I could use
some help from anyone with experience in building postgresql or
libpqxx on OSX, esp. against the macport libraries.

Thanks, Darren

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] [HACKERS] macport for libpqxx

2008-09-20 Thread Darren Weber
Hi Dave,

Thanks for getting back to me.  Please find attached a draft Portfile
for libpqxx-2.6.9 (the stable version).  It's easy to read the
Portfile to see what is going on.  I think it should work fine, but I
would appreciate any advice about any configure options that should be
enabled.

I've got a problem within macports (not specific to pg or libpqxx).
MacPorts will not locate the pg_config.sh file during the macport
build.  I can't just modify the $PATH env because the macport build
ignores it.  There is an internal variable called $binpath in
macports, but it's read-only.  I can't figure out how to get the
macport configure process to find the right pg_config.  Any help
appreciated.

Thanks, Darren

PS, If you want to try out this Portfile, take a look at the macports
guide (esp. sections 4,5):
http://guide.macports.org/chunked/
Then follow the instructions to create your local repository here:
http://guide.macports.org/chunked/development.local-repositories.html
Then put this Portfile into databases/libpqxx within your repository.



On Sat, Sep 20, 2008 at 12:27 AM, Dave Page [EMAIL PROTECTED] wrote:
 On Sat, Sep 20, 2008 at 7:30 AM, Darren Weber
 [EMAIL PROTECTED] wrote:
 http://pqxx.org/development/libpqxx/

 I'm in the process of creating a macport for libpqxx.  I could use
 some help from anyone with experience in building postgresql or
 libpqxx on OSX, esp. against the macport libraries.

 Never built libpqxx or a MacPort), but I'm used to building Postgres
 and other PG apps and the fu required to get universal binaries. What
 do you need?

 --
 Dave Page
 EnterpriseDB UK: http://www.enterprisedb.com



Portfile
Description: video/flv

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] postgres user account on OSX

2008-09-10 Thread Darren Weber
There is a postgres user account on my OSX system.  I'm not clear
about how it was created.  I've installed a binary version of 8.3 in
/Library/PostgreSQL/8.3/ and built another version from source into
/usr/local/pgsql/.  When I login as root and then 'su - postgres' it
takes me to the postgres account and the user directory is at
/opt/local/var/db/postgresql83/.

Can someone explain how this user account was created?

I'm trying to start the server that I built from source but it will
not create a logfile, ie:

elegans:~ postgres$ /usr/local/pgsql/bin/pg_ctl -D
/usr/local/pgsql/data -l logfile start
server starting
sh: logfile: Permission denied
elegans:~ postgres$
elegans:~ postgres$ nohup /usr/local/pgsql/bin/postgres -D
/usr/local/pgsql/data /dev/null server.log 21 /dev/null 
[1] 28696
elegans:~ postgres$ -sh: server.log: Permission denied
elegans:~ postgres$
elegans:~ postgres$ pwd
/opt/local/var/db/postgresql83
elegans:~ postgres$
elegans:~ postgres$ ls -al ..
total 0
drwxr-xr-x  4 root  admin  136 Aug 28 12:05 .
drwxr-xr-x  8 root  admin  272 Sep  9 14:49 ..
drwxr-xr-x  3 root  admin  102 Aug 28 12:05 postgresql83
drwxr-xr-x  3 root  admin  102 Aug 26 13:06 smb


Should I remove this user somehow and replace it with a standard user
(using the system admin GUI)?

Thanks, Darren

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] using a GUI front end to postgres

2008-09-10 Thread Darren Weber
What's the best open-source front-end for rapid GUI query and report
generation using postgres?

Is it possible to use MS access as a front-end to postgres for rapid
prototyping?  Can that be done through ODBC?

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] OS X library path issues for libpq (ver 8.3)

2008-09-09 Thread Darren Weber
On Tue, Sep 9, 2008 at 12:46 AM, Dave Page [EMAIL PROTECTED] wrote:
 On Tue, Sep 9, 2008 at 2:02 AM, Darren Weber
 [EMAIL PROTECTED] wrote:
 I'm new to using PostgreSQL on mac OS X.  I used a binary installer
 for PostgreSQL 8.3 on mac OS X 10.5, which installs into

 /Library/PostgreSQL/[version]/

 I'm building a lot of software that links to libpq and most of the
 builds fail or the run-time fails, because it cannot find the
 PostgreSQL libraries by default.  It seems the dynamic link loader
 doesn't search this path by default to locate dynamic libraries, like
 libpq.5.dylib.

 Can you fix this issue for the binary installer?

 Hmm, it seems this is a side-effect of not rewriting the shared
 library paths at installation time. Because the library ID is just the
 filename, the linker doesn't write the full path to the binaries you
 compile.

 We changed from the old behaviour after it became apparent that the
 utilities we needed to rewrite the paths are on available on machines
 with XCode installed.

 I would suggest doing one of the following:

 sudo ln -s /Library/PostgreSQL/8.3/lib/libpq.5.dylib /usr/lib/libpq.5.dylib

 which will put a symlink to the library in /usr/lib, where the dynamic
 loader will find it, or:

 export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Library/PostgreSQL/8.3/lib

 which will tell the dynamic linker to look in the PG lib directory. A
 third possible fix would be to use install_name_tool to rewrite the
 shared library path in the executable you've built.

 I'll look at a solution for the installer - it'll probably have to be
 the symlink unless anyone else has a better idea...

 --
 Dave Page
 EnterpriseDB UK:   http://www.enterprisedb.com



I guess the symlinks from /usr/lib to /Library/PostgreSQL/lib would
have to happen for many items (and sub-directories).

I'm still new to OS X, so the whole unix/NeXT integration issue is a
black box to me.  At this point, I'm leaning on unix but I'm getting
tangled up in binary installers that create some nice .app bundles.
That's great for that particular package, but I'm discovering that OS
X is confusing me when it comes to building (ie compiling) many useful
packages from source (most of them assume a unix build environment).
I'm using macports, but they decided to use /opt for all the
installations and I'm not entirely clear about how that integrates
with the OS X unix system (in some cases it seems to conflict).
Yadda, yadda, yadda

For one thing, I've discovered that setting DYLD_LIBRARY_PATH is not a
great idea on OS X.  For one, if you set it in your shell login
profiles (.bashrc, .profile, .cshrc or whatever), most applications
that are started from the 'Finder' will not see that setting (so it's
kinda useless unless you want to work from the terminal all day).
Also, some discussion forums indicate that it can screw up some
applications.  From reading 'man dyld', I gather that setting this
variable is useful for testing new libraries rather than a permanent
library solution.

Today, I'm going to follow instructions here:
http://developer.apple.com/internet/opensource/postgres.html

If that doesn't work for me, I'll fall back on macports.  However,
both of these solutions involve building from source and they may not
generate the .app utilities.

Best, Darren

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] OS X library path issues for libpq (ver 8.3)

2008-09-09 Thread Darren Weber
On Tue, Sep 9, 2008 at 11:55 AM, Benjamin Reed [EMAIL PROTECTED] wrote:
 On Tue, Sep 9, 2008 at 2:46 PM, Dave Page [EMAIL PROTECTED] wrote:

 For one thing, I've discovered that setting DYLD_LIBRARY_PATH is not a
 great idea on OS X.  For one, if you set it in your shell login
 profiles (.bashrc, .profile, .cshrc or whatever), most applications
 that are started from the 'Finder' will not see that setting (so it's
 kinda useless unless you want to work from the terminal all day).

 Yup.

 Correct.  If you need the behavior of LD_LIBRARY_PATH on
 linux/solaris, use DYLD_FALLBACK_LIBRARY_PATH instead.
 DYLD_LIBRARY_PATH doesn't do what you think.  It's the nuclear option.

 Also, some discussion forums indicate that it can screw up some
 applications.  From reading 'man dyld', I gather that setting this
 variable is useful for testing new libraries rather than a permanent
 library solution.

 Today, I'm going to follow instructions here:
 http://developer.apple.com/internet/opensource/postgres.html

 That's very old. I'd stick with the installer or MacPorts.

 Or Fink.  ;)

 --
 Benjamin Reed a.k.a. Ranger Rick
 Fink, KDE, and Mac OS X development

 Blog: http://www.raccoonfink.com/
 Music: http://music.raccoonfink.com/



Yeah, I also found that fink conflicts with macports.  I do like the
idea of using the Debian repository and package management system.
For some reason, which escapes me now, I went with macports (maybe it
was just that macports gave me an emacs.app - poor reason actually).
Yet another learning curve for OSX.  All this confusion makes me
appreciate the beauty of Debian systems (eg, Ubuntu), with regard to
package management.  I hope all this mucking around with OSX is going
to pay-off sooner or later.

I guess the best suggestion (maybe the best solution) in this thread
to date is to hack that symlink and hope the build system (and
run-time links) will work everything out from there.  Using the binary
installer is easier and provides more GUI apps than doing the source
build.  I've done a quick, standard source build and install into
/usr/local/pgsql/, can this co-exist with the binary installation into
/Library/PostgreSQL/[version]?

FYI, just to illustrate some of the confusion I can see.  For
starters, we need gmake.  Well:

[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# gmake
-sh: gmake: command not found
[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for powerpc-apple-darwin9.0
[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# ls -l /usr/bin/make
lrwxr-xr-x 1 root wheel 7 2008-08-22 17:43 /usr/bin/make - gnumake*


OK, but it's curious that I'm running OS X (10.5; Darwin 9.4.0) on a
mac pro with dual quad-core zeons and the make program was built for
Darwin 9.0 on a powerpc!  (Looking to the heavens, I wonder how the
hell can that work?)  It does work, but maybe I should build it to get
the architecture right (maybe everything should be built from the
ground up!), so:

[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# port search gmake
gmake  devel/gmake3.81 GNU Make
[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# port install gmake
---  Fetching gmake
---  Attempting to fetch make-3.81.tar.bz2 from http://ftp.gnu.org/gnu/make
---  Verifying checksum(s) for gmake
---  Extracting gmake
---  Configuring gmake
---  Building gmake with target all
---  Staging gmake into destroot
---  Installing gmake 3.81_0
---  Activating gmake 3.81_0
---  Cleaning gmake
[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# which gmake
/opt/local/bin/gmake
[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# gmake --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-apple-darwin9.4.0
[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# which gmake
/opt/local/bin/gmake




A bit more intrigue; I'm reading the options for building postgreSQL
8.3.3 and I check the system for libperl and libpython, ie:

[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# locate libperl
/System/Library/Perl/5.8.8/darwin-thread-multi-2level/CORE/libperl.dylib
/System/Library/Perl/lib/5.8/libperl.dylib
/opt/local/lib/perl5/5.8.8/darwin-2level/CORE/libperl.a
/opt/local/var/macports/software/perl5.8/5.8.8_3+darwin_9/opt/local/lib/perl5/5.8.8/darwin-2level/CORE/libperl.a
/usr/libexec/httpd/libperl.so

[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# locate libpython
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.0.sdk/usr/lib/libpython.dylib

Re: [GENERAL] OS X library path issues for libpq (ver 8.3)

2008-09-09 Thread Darren Weber
On Tue, Sep 9, 2008 at 1:31 PM, Dave Page [EMAIL PROTECTED] wrote:
 On Tue, Sep 9, 2008 at 9:14 PM, Darren Weber
 [EMAIL PROTECTED] wrote:

 Yeah, I also found that fink conflicts with macports.  I do like the
 idea of using the Debian repository and package management system.
 For some reason, which escapes me now, I went with macports (maybe it
 was just that macports gave me an emacs.app - poor reason actually).
 Yet another learning curve for OSX.  All this confusion makes me
 appreciate the beauty of Debian systems (eg, Ubuntu), with regard to
 package management.  I hope all this mucking around with OSX is going
 to pay-off sooner or later.

 It will. My advice, is to pick one packaging system for your
 build-from-source addons, and stick with it. I prefer MacPorts,
 Benjamin is a Fink man.

 I guess the best suggestion (maybe the best solution) in this thread
 to date is to hack that symlink and hope the build system (and
 run-time links) will work everything out from there.  Using the binary
 installer is easier and provides more GUI apps than doing the source
 build.  I've done a quick, standard source build and install into
 /usr/local/pgsql/, can this co-exist with the binary installation into
 /Library/PostgreSQL/[version]?

 Yes. I regularly have half a dozen or more installs of PostgreSQL and
 Postgres Plus (EnterpriseDB's version of PostgreSQL) on the same box -
 including source and installer builds.

 FYI, just to illustrate some of the confusion I can see.  For
 starters, we need gmake.  Well:

 Use make from XCode. It is gmake.


 OK, but it's curious that I'm running OS X (10.5; Darwin 9.4.0) on a
 mac pro with dual quad-core zeons and the make program was built for
 Darwin 9.0 on a powerpc!  (Looking to the heavens, I wonder how the
 hell can that work?)  It does work, but maybe I should build it to get
 the architecture right (maybe everything should be built from the
 ground up!), so:

 Use the file command to check what type of binary it is. If it really
 is a PPC binary, then it'll be running under Rosetta
 (http://www.apple.com/rosetta/). Otherwise, it's probably a universal
 binary which contains PPC and Intel executables in the same file.

 A bit more intrigue; I'm reading the options for building postgreSQL
 8.3.3 and I check the system for libperl and libpython, ie:

 ...

 Whoa, talk about a real supermarket full of the same libraries.  I
 know that every-man and his dog has their own opinion on the pure
 installation system (maybe it's a bit like belief in one or many
 gods?).  Anyhow, I have to figure out what the default search path is
 for the linker (ie, how to avoid total paranoia about configuring
 builds).

 You'll almost always use the stuff under
 /Developer/SDKs/MacOSX10.5.sdk, which is the Leopard SDK. Substitute
 in /opt if you need non-standard versions of anything, or additional
 libraries from MacPorts (or Fink). You've also got the Tiger SDK and
 at least some of the iphone SDK there.

 Looks like I've got my work cut out for me before I even begin to
 develop anything.

 It's really not that difficult - unless you need universal binaries,
 or want to target older versions of OSX, you won't normally see
 anything different from Linux for example.

 --
 Dave Page
 EnterpriseDB UK: http://www.enterprisedb.com



When building postgreSQL from source, I'm using a default installation
path config and I want to be specific about what libraries are being
linked, so it seems that I could use macports like this (assuming the
required ports are installed and active):

./configure  \
  --with-includes=/opt/local/include  \
  --with-libraries=/opt/local/lib  \
  --with-perl --with-python --with-tcl

On the other hand, I could use the /Developer SDK, like this:

./configure \
  --with-includes=/Developer/SDKs/MacOSX10.5.sdk/usr/include  \
  --with-libraries=/Developer/SDKs/MacOSX10.5.sdk/usr/lib  \
  --with-perl --with-python --with-tcl

The /Developer SDK for 10.5 seems to be symlinks to the /System
frameworks (this is a 10.5 system), eg:

[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# ls -l
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython.dylib lrwxr-xr-x 1
root wheel 16 2008-08-22 17:40
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython.dylib -
libpython2.dylib*
[ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# ls -l
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython2.dylib
lrwxr-xr-x 1 root wheel 68 2008-08-22 17:40
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython2.dylib -
../../System/Library/Frameworks/Python.framework/Versions/2.5/Python*

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] OS X library path issues for libpq (ver 8.3)

2008-09-09 Thread Darren Weber
On Tue, Sep 9, 2008 at 2:03 PM, Darren Weber
[EMAIL PROTECTED] wrote:
 On Tue, Sep 9, 2008 at 1:31 PM, Dave Page [EMAIL PROTECTED] wrote:
 On Tue, Sep 9, 2008 at 9:14 PM, Darren Weber
 [EMAIL PROTECTED] wrote:

 Yeah, I also found that fink conflicts with macports.  I do like the
 idea of using the Debian repository and package management system.
 For some reason, which escapes me now, I went with macports (maybe it
 was just that macports gave me an emacs.app - poor reason actually).
 Yet another learning curve for OSX.  All this confusion makes me
 appreciate the beauty of Debian systems (eg, Ubuntu), with regard to
 package management.  I hope all this mucking around with OSX is going
 to pay-off sooner or later.

 It will. My advice, is to pick one packaging system for your
 build-from-source addons, and stick with it. I prefer MacPorts,
 Benjamin is a Fink man.

 I guess the best suggestion (maybe the best solution) in this thread
 to date is to hack that symlink and hope the build system (and
 run-time links) will work everything out from there.  Using the binary
 installer is easier and provides more GUI apps than doing the source
 build.  I've done a quick, standard source build and install into
 /usr/local/pgsql/, can this co-exist with the binary installation into
 /Library/PostgreSQL/[version]?

 Yes. I regularly have half a dozen or more installs of PostgreSQL and
 Postgres Plus (EnterpriseDB's version of PostgreSQL) on the same box -
 including source and installer builds.

 FYI, just to illustrate some of the confusion I can see.  For
 starters, we need gmake.  Well:

 Use make from XCode. It is gmake.


 OK, but it's curious that I'm running OS X (10.5; Darwin 9.4.0) on a
 mac pro with dual quad-core zeons and the make program was built for
 Darwin 9.0 on a powerpc!  (Looking to the heavens, I wonder how the
 hell can that work?)  It does work, but maybe I should build it to get
 the architecture right (maybe everything should be built from the
 ground up!), so:

 Use the file command to check what type of binary it is. If it really
 is a PPC binary, then it'll be running under Rosetta
 (http://www.apple.com/rosetta/). Otherwise, it's probably a universal
 binary which contains PPC and Intel executables in the same file.

 A bit more intrigue; I'm reading the options for building postgreSQL
 8.3.3 and I check the system for libperl and libpython, ie:

 ...

 Whoa, talk about a real supermarket full of the same libraries.  I
 know that every-man and his dog has their own opinion on the pure
 installation system (maybe it's a bit like belief in one or many
 gods?).  Anyhow, I have to figure out what the default search path is
 for the linker (ie, how to avoid total paranoia about configuring
 builds).

 You'll almost always use the stuff under
 /Developer/SDKs/MacOSX10.5.sdk, which is the Leopard SDK. Substitute
 in /opt if you need non-standard versions of anything, or additional
 libraries from MacPorts (or Fink). You've also got the Tiger SDK and
 at least some of the iphone SDK there.

 Looks like I've got my work cut out for me before I even begin to
 develop anything.

 It's really not that difficult - unless you need universal binaries,
 or want to target older versions of OSX, you won't normally see
 anything different from Linux for example.

 --
 Dave Page
 EnterpriseDB UK: http://www.enterprisedb.com



 When building postgreSQL from source, I'm using a default installation
 path config and I want to be specific about what libraries are being
 linked, so it seems that I could use macports like this (assuming the
 required ports are installed and active):

 ./configure  \
  --with-includes=/opt/local/include  \
  --with-libraries=/opt/local/lib  \
  --with-perl --with-python --with-tcl

 On the other hand, I could use the /Developer SDK, like this:

 ./configure \
  --with-includes=/Developer/SDKs/MacOSX10.5.sdk/usr/include  \
  --with-libraries=/Developer/SDKs/MacOSX10.5.sdk/usr/lib  \
  --with-perl --with-python --with-tcl

 The /Developer SDK for 10.5 seems to be symlinks to the /System
 frameworks (this is a 10.5 system), eg:

 [ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# ls -l
 /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython.dylib lrwxr-xr-x 1
 root wheel 16 2008-08-22 17:40
 /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython.dylib -
 libpython2.dylib*
 [ [EMAIL PROTECTED] /usr/src/postgresql-8.3.3 ]# ls -l
 /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython2.dylib
 lrwxr-xr-x 1 root wheel 68 2008-08-22 17:40
 /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython2.dylib -
 ../../System/Library/Frameworks/Python.framework/Versions/2.5/Python*



Curious, even after using the /Developer includes and lib for
configure, the config.log file contains the following:


PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /usr/bin
PATH: /bin
PATH: /usr/sbin
PATH: /sbin
PATH: /usr/local/bin
PATH: /usr/X11/bin
PATH: /opt/local/bin
PATH: /usr/local/git/bin
PATH: /usr/local/mysql/bin
PATH: /usr

[GENERAL] OSX build of PostgreSQL 8.3.3 with macports

2008-09-09 Thread Darren Weber
For the record, I've found the following kitchen sink options will
build and install on OS X 10.5 with macports.

sudo -i

port install gmake
port install gawk
port install flex
port install bison +yacc
port install openldap
port install openssl
port install libxml
port install libxml2
port install libxmldiff
port install libxmlxx
port install libxmlxx2
port install python25
port install perl5.8 +darwin_9 +threads +shared
port install tcl +threads

## Some of these ports may replace a currently installed port.
## Use 'port deactivate XXX' on the currently installed port XXX.
## Then run the install again to enable the new port.
## Use 'port variants XXX' to identify install candidates.

mkdir -p /usr/src
cd /usr/src
curl -O 
ftp://ftp5.us.postgresql.org/pub/PostgreSQL/source/v8.3.3/postgresql-8.3.3.tar.gz
tar zxvf postgresql*.tar.gz
cd postgresql-8.3.3
./configure \
--with-includes=/opt/local/include \
--with-libraries=/opt/local/lib \
--with-perl --with-python --with-tcl \
--with-krb5 --with-gssapi --with-pam \
--with-ldap --with-openssl --enable-thread-safety \
--with-bonjour --with-libxml --with-libxslt \
--with-system-tzdata=/usr/share/zoneinfo

## Check config.log to confirm where it found libraries

gmake
# Wait for All of PostgreSQL successfully made. Ready to install.
gmake install
# Wait for PostgreSQL installation complete.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] OS X library path issues for libpq (ver 8.3)

2008-09-08 Thread Darren Weber
I'm new to using PostgreSQL on mac OS X.  I used a binary installer
for PostgreSQL 8.3 on mac OS X 10.5, which installs into

/Library/PostgreSQL/[version]/

I'm building a lot of software that links to libpq and most of the
builds fail or the run-time fails, because it cannot find the
PostgreSQL libraries by default.  It seems the dynamic link loader
doesn't search this path by default to locate dynamic libraries, like
libpq.5.dylib.

Can you fix this issue for the binary installer?

Thanks!

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general