necessary info

[John B Brown]

Dear Folk,

	After remembering I still have Applecare, I called support and asked 
how to uninstall the X11 installed set. I never realized the ease with 
which a package can be uninstalled on this system; remove it from the 
install folder in Finder, put it on the desktop, and reboot. Being a 
belt and suspender sort of guy, I trashed both the plist and the app 
before the reboot.

	Not so difficult after all.

	So, now I'll install XQuartz-2.5.0; the present installed OS is 
supplied from the MacOSUpdCombo10.6.3v1.1.dmg which may have broken X11 
when it went in. Who's to know?

	Shalom,

	John B. Brown.
	[jbb at vcn.com]
	358 High Street,
	Buffalo, Wyoming
	82834

"Freedom is not worth having if it does not include
the freedom to make mistakes"  Mahatma Gandhi
"If any question why we died, tell them,
because our fathers lied."  Rudyard Kipling
"A man who does not know the truth is just an idiot
but a man who knows the truth and calls it a lie
is a crook."  Bertolt Brecht
"I wonder whether the world is being run
by smart people who are putting us on
or by imbeciles who really mean it."  Mark Twain

On 4/29/10 10:46 AM, Michael Funk wrote:
> 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
>
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
>