Thread: OS X library path issues for libpq (ver 8.3)
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!
On Tue, Sep 9, 2008 at 2:02 AM, Darren Weber <darren.weber.lists@gmail.com> 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
On Tue, Sep 9, 2008 at 3:46 AM, Dave Page <dpage@pgadmin.org> wrote: > I'll look at a solution for the installer - it'll probably have to be > the symlink unless anyone else has a better idea... Another option would be to create them as actual frameworks; instead of libpq you'd have /Library/Frameworks/pq.framework (and all the files/directories as required) and then people could compile with "-framework pq" and the OSX linker would do the write thing without having to dirty a system library path (/usr/lib) with symlinks. -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/
On Tue, Sep 9, 2008 at 2:23 PM, Benjamin Reed <rangerrick@gmail.com> wrote: > On Tue, Sep 9, 2008 at 3:46 AM, Dave Page <dpage@pgadmin.org> wrote: > >> I'll look at a solution for the installer - it'll probably have to be >> the symlink unless anyone else has a better idea... > > Another option would be to create them as actual frameworks; instead > of libpq you'd have /Library/Frameworks/pq.framework (and all the > files/directories as required) and then people could compile with > "-framework pq" and the OSX linker would do the write thing without > having to dirty a system library path (/usr/lib) with symlinks. Agreed, though I think that's something that should be handled by the PostgreSQL build system. Plus, I doubt it would be directly supported by many apps for some time - pgAdmin certainly wouldn't like it, nor would Slony. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Tue, Sep 9, 2008 at 12:46 AM, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Sep 9, 2008 at 2:02 AM, Darren Weber > <darren.weber.lists@gmail.com> 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
On Tue, Sep 9, 2008 at 6:35 PM, Darren Weber <darren.weber.lists@gmail.com> 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
On Tue, Sep 9, 2008 at 2:46 PM, Dave Page <dpage@pgadmin.org> 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/
"Benjamin Reed" <rangerrick@gmail.com> writes:
> On Tue, Sep 9, 2008 at 3:46 AM, Dave Page <dpage@pgadmin.org> wrote:
>> I'll look at a solution for the installer - it'll probably have to be
>> the symlink unless anyone else has a better idea...
> Another option would be to create them as actual frameworks; instead
> of libpq you'd have /Library/Frameworks/pq.framework (and all the
> files/directories as required) and then people could compile with
> "-framework pq" and the OSX linker would do the write thing without
> having to dirty a system library path (/usr/lib) with symlinks.
Uh, it's not apparent to me why dropping stuff into /Library is any
better than dropping it into /usr/lib?
regards, tom lane
On Tue, Sep 9, 2008 at 11:55 AM, Benjamin Reed <rangerrick@gmail.com> wrote: > On Tue, Sep 9, 2008 at 2:46 PM, Dave Page <dpage@pgadmin.org> 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: [ root@elegans /usr/src/postgresql-8.3.3 ]# gmake -sh: gmake: command not found [ root@elegans /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 [ root@elegans /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: [ root@elegans /usr/src/postgresql-8.3.3 ]# port search gmake gmake devel/gmake 3.81 GNU Make [ root@elegans /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 [ root@elegans /usr/src/postgresql-8.3.3 ]# which gmake /opt/local/bin/gmake [ root@elegans /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 [ root@elegans /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: [ root@elegans /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 [ root@elegans /usr/src/postgresql-8.3.3 ]# locate libpython /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.0.sdk/usr/lib/libpython.dylib /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.0.sdk/usr/lib/libpython2.5.dylib /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.0.sdk/usr/lib/libpython2.dylib /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libpython.dylib /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libpython2.3.dylib /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libpython2.dylib /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython.dylib /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython2.5.dylib /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpython2.dylib /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/libpython2.5.a /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/libpython2.5.a /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/libpython2.4.dylib /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/libpython2.5.dylib /opt/local/lib/libpython2.4.dylib /opt/local/lib/libpython2.5.dylib /opt/local/lib/python2.4/config/libpython2.4.a /opt/local/lib/python2.5/config/libpython2.5.a /opt/local/var/macports/software/python24/2.4.5_3+darwin_9/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/libpython2.4.dylib /opt/local/var/macports/software/python24/2.4.5_3+darwin_9/opt/local/lib/libpython2.4.dylib /opt/local/var/macports/software/python24/2.4.5_3+darwin_9/opt/local/lib/python2.4/config/libpython2.4.a /opt/local/var/macports/software/python25/2.5.2_5+darwin_9/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/libpython2.5.dylib /opt/local/var/macports/software/python25/2.5.2_5+darwin_9/opt/local/lib/libpython2.5.dylib /opt/local/var/macports/software/python25/2.5.2_5+darwin_9/opt/local/lib/python2.5/config/libpython2.5.a /usr/lib/libpython.dylib /usr/lib/libpython2.5.dylib /usr/lib/libpython2.dylib [ root@elegans /usr/src/postgresql-8.3.3 ]# 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). Looks like I've got my work cut out for me before I even begin to develop anything. Cheers! (I'm gonna need a drink.)
On Tue, Sep 9, 2008 at 9:14 PM, Darren Weber <darren.weber.lists@gmail.com> 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
On Tue, Sep 9, 2008 at 3:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Uh, it's not apparent to me why dropping stuff into /Library is any > better than dropping it into /usr/lib? Because /Library is the Apple framework equivalent of /usr/local in unix-world. Whereas /usr/lib should not really be touched by anyone but Apple (or the system vendor, for that matter, on any unix). /Library is searched automatically by the linker when doing framework-style builds, without needing -F to find a specific location for it. -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/
On Tue, Sep 9, 2008 at 4:14 PM, Darren Weber <darren.weber.lists@gmail.com> 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. Generally they co-exist fine at runtime, but if you're building in one or the other, you should make sure it's counterpart is not enabled in your shell. That said, they're reasonably close to each other feature-wise, and the best bet is to pick which one you're more comfortable with (BSD ports style, or Linux/Debian style). -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/
On Tue, Sep 9, 2008 at 1:31 PM, Dave Page <dpage@pgadmin.org> wrote: > On Tue, Sep 9, 2008 at 9:14 PM, Darren Weber > <darren.weber.lists@gmail.com> 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: [ root@elegans /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* [ root@elegans /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*
On Tue, Sep 9, 2008 at 2:03 PM, Darren Weber <darren.weber.lists@gmail.com> wrote: > On Tue, Sep 9, 2008 at 1:31 PM, Dave Page <dpage@pgadmin.org> wrote: >> On Tue, Sep 9, 2008 at 9:14 PM, Darren Weber >> <darren.weber.lists@gmail.com> 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: > > [ root@elegans /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* > [ root@elegans /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/texbin PATH: /usr/local/Trolltech/Qt-4.4.1/bin PATH: /opt/local/bin PATH: /opt/local/sbin ...(oh yea, that path has redundancy baby, but it's not intentional :-o) No sign there of anything in /Developer/... configure:5280: checking for perl configure:5298: found /opt/local/bin/perl configure:5310: result: /opt/local/bin/perl configure:5319: checking for Perl archlibexp configure:5322: result: /opt/local/lib/perl5/5.8.8/darwin-2level configure:5324: checking for Perl privlibexp configure:5327: result: /opt/local/lib/perl5/5.8.8 configure:5329: checking for Perl useshrplib configure:5332: result: false configure:5335: checking for flags to link embedded Perl configure:5340: result: -L/opt/local/lib -L/usr/local/lib /opt/local/lib/perl5/5.8.8/darwin-2level/auto/DynaLoader/DynaLoader.a -L/opt/local/lib/perl5/5.8.8/darwi n-2level/CORE -lperl -ldl -lm -lutil -lc configure:5347: checking for python configure:5365: found /opt/local/bin/python configure:5377: result: /opt/local/bin/python configure:5391: checking for Python distutils module configure:5395: result: yes configure:5404: checking Python configuration directory configure:5411: result: /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config configure:5415: checking how to link an embedded Python application configure:5436: result: -L/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config -lpython2.5 -ldl configure:5441: checking whether Python is compiled with thread support configure:5445: result: yes So the build config is picking up all the macport perl and python installations.