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

On Tue, Sep 9, 2008 at 2:03 PM, Darren Weber
<darren(dot)weber(dot)lists(at)gmail(dot)com> wrote:
> On Tue, Sep 9, 2008 at 1:31 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> On Tue, Sep 9, 2008 at 9:14 PM, Darren Weber
>> <darren(dot)weber(dot)lists(at)gmail(dot)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(at)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(at)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.