necessary info

[Michael Funk]

On Apr 29, 2010, at 8:55 AM, John B Brown wrote:

> jbb at pinball3:~
> (7): % locate libtiff
> /Library/Printers/hp/Utilities/HPPU Plugins/ZMeasurement.assistant/Contents/Resources/libtiff_copyright.txt
> /src/gnu/LIBS/libtiff-lzw-1.3.tar.gz
> /src/gnu/LIBS/libtiff-lzw-1.5.tgz
> /src/gnu/LIBS/libtiff-lzw-1.5.tgz.md5
> /System/Library/Tcl/8.4/Img1.4/libtifftcl3.8.2.dylib
> /System/Library/Tcl/8.5/Img1.4/libtifftcl3.8.2.dylib
> /Users/jbb/google-earth/libtiff.so.3
> /usr/lib/libtiff.3.6.0.dylib
> /usr/lib/libtiff.a
> /usr/lib/libtiff.dylib
> /usr/lib/libtiff.so
> /usr/local/man/man3/libtiff.3t

The libtiff in /usr/lib could definitely be a problem, I wonder if that's what's getting loaded instead of the one in the ImageIO directory.  You can tell its version by doing an 'otool -L /usr/lib/libtiff.dylib'.  In general /usr/lib is the domain of the OS vendor, nothing should be going in there aside from what the OS installer puts there (there is no /usr/lib/libtiff* on a stock system).  That's why MacPorts puts everything under /opt/local by default.

Actually, from a previous email you said that your DYLD_LIBRARY_PATH was set to the following:

DYLD_LIBRARY_PATH=/opt/local/lib:/usr/lib:/usr/X11/lib:/opt/schily/lib:/usr/local/lib

You don't need to have /usr/lib in there (or shouldn't need it).  dyld uses full pathnames embedded in the binary header to resolve
references to shared libraries.  DYLD_LIBRARY_PATH is used to override this behavior.  There's no need to set it at all unless you're debugging a different build of a library or otherwise want to forcibly change which shared libraries are loaded from which directories.  You probably don't need to define DYLD_LIBRARY_PATH at all, and probably shouldn't be setting it.

By putting a custom build of libtiff in /usr/lib, and including /usr/lib in DYLD_LIBRARY_PATH, anything that needs to load libtiff.dylib will load your custom build of libtiff instead of the one it was intended to run with.  By default the filesystem is case-preserving but not case-sensitive ("LS" works just as well as "ls"), so libtiff.dylib looks just like libTIFF.dylib to dyld when it's resolving references for ImageIO.

  Mike