On Tue, Sep 9, 2008 at 6:35 PM, Darren Weber <darren.weber.lists@xxxxxxxxx> wrote: > I guess the symlinks from /usr/lib to /Library/PostgreSQL/lib would > have to happen for many items (and sub-directories). No, just one link to libpq.5.dylib. There's nothing else in there you'd should need to link with, except for very tightly integrated packages such as Slony, which you'd probably want to install in the PostgreSQL tree anyway (if not, your probably the sort of person who would be building the server from source as well anyway). > 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.... Yeah, I use Macports as well. For the most part, it doesn't integrate with OS X - that's why it's all kept under /opt. > 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. > 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. > 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. Oh, they won't. You won't find many apps in MacPorts that do I'd wager - just a few GUI ones which don't use X11 (such as pgAdmin). -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
