Re: OS X library path issues for libpq (ver 8.3) - Mailing list pgsql-general

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.)