0

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.

Community
  • 1
  • 1
Jonathan Vanasco
  • 15,111
  • 10
  • 48
  • 72
  • You have to look at how your library is linked (by running `otool -L` against it). If it has hardcoded absolute paths in it, you have no choice but to use `install_name_tool` to change them (unless you want to symlink the dependencies into the absolute paths it wants). – abarnert Aug 01 '13 at 18:35
  • By the way, that's an odd install layout—it's sort of like a framework, and sort of like a traditional Unix /opt subdirectory, but not actually like either. So, I'm not sure you can expect standard OS X mechanisms to work with it transparently. – abarnert Aug 01 '13 at 18:36
  • sorry, should have mentioned that. i had already checked via otool (it was the first thing I thought of); everything concerned is just the library name ( only one hardcoded path, concerning something else ). for whatever reason(s), python just doesn't want to look outside of /usr/local/lib – Jonathan Vanasco Aug 01 '13 at 18:51

1 Answers1

2

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

abarnert
  • 354,177
  • 51
  • 601
  • 671
  • thanks. i was talking with a friend who used to manage some of the more popular package installers and he corrected me with `DYLD_FALLBACK_LIBRARY_PATH` too. I'll give that a shot tonight. He also suggested fixing the _psycopg.so by using `install_name_tool` to address the correct libraries. I'm going to look into that too. – Jonathan Vanasco Aug 01 '13 at 20:18