I figured out what the underlying problem is with many of the current osx installations ( such as http://psycopg.lighthouseapp.com/projects/62710/tickets/111-library-not-loaded-libssl100dylib and python pip install psycopg2 install error )
A lot of people use the PostgreSQL installer from EnterpriseDB ; probably because it's the first option in http://www.postgresql.org/download/macosx/
If you install with that, it installs all the needed binaries and libraries into it's private versioned space...
ie
/Library/PostgreSQL/9.2/bin
/Library/PostgreSQL/9.2/lib
/Library/PostgreSQL/8.4.5/bin
/Library/PostgreSQL/8.4.5/lib
If I run pg_config ( which points to the /Library/PostgreSQL/v/bin/pg_config ) it shoes the right info
LIBDIR = /Library/PostgreSQL/9.2/lib
However, all the errors from importing psycopg2 seem to show that psycopg2 is trying to load out of /usr/local/lib and not the lib that it was compiled against ( or should be expecting )
I tried using environment vars ( LD_LIBRARY_PATH , LD_PRELOAD ) but can't seem to make this work. Unless the (correct) files are /usr/local/lib , psycopg2 doesn't want to import.
I don't like the solution that others have mentioned here to rewrite or link these files; there's got to be a way to force Python / psycopg2 to use the intended filepaths.
Your problem is that you're using the wrong environment variables.
LD_LIBRARY_PATH is used by the link-loaders for linux/glibc, FreeBSD, and some other *nix platforms, but not for the Mac OS X link-loader. See the manpage for dyld for what does exist.
The obvious replacement is DYLD_LIBRARY_PATH. However, this is probably not what you want (for really the same basic reasons LD_LIBRARY_PATH usually what you want on linux, but the details are different). Instead, you probably want DYLD_FALLBACK_LIBRARY_PATH. Briefly, what this does is change the fallback search paths (normally ~/lib:/usr/local/lib:/lib:/usr/lib) used for libraries not found in the primary search paths, instead of changing the primary search paths, so you can provide missing libraries, without blocking libraries that actually exist. (Try running, e.g., any X11 app each way for a very simple demonstration of the difference.) The manpage explains the details.
(By the way, if you're wondering what's so special about OS X's link-loader that they felt the need to use different environment variables, it's mainly about frameworks and versioning, although the custom magic paths you can embed are also relevant. Someone at NeXT or Apple presumably felt it would be more misleading than helpful to use the same names to mean something 80% the same but 20% different…)
