Yes, that's the plan, but you have to keep in mind that I don't have Mac and have never owned one, so my abilities are limited here.
I compiled libtiff myself and I don't remember linking it against any other libraries. On Windows that's just stand alone library, so I am surprised that it needs some third party files on Mac... And I can not even reproduce this error, since on the Mac I used to compile it all these libraries were there to begin with.
Trying to look into it, anyway! Thanks a lot for your input!
no problem, yes it is difficult doing this stuff blind.
for whatever reason, the libtiff shipped with StarNet_MacOS has the following undefined symbols, which i guess compels dyld to look for them:
among others, but they look like stdlib, etc. stuff.
so the /usr/lib path i indicated above is just peculiar to that machine where i have homebrew installed - dyld is looking there, which makes sense. on my desktop machine where i have MacPorts installed, i could not satisfy all the dependencies for whatever reason, but if i just make a symlink to /opt/local/lib/libtiff.5.dylib then that libtiff gets loaded and all it's dependencies are satisfied by dylibs in /opt/local/lib.
which brings me to this - the undefined symbols in /opt/local/libtiff.5.dylib are different than the ones shown above. notably libtiff from macports has no WebP symbols... which says to me that WebP support must be a compile-time option for libtiff, as could be jpeg support. so maybe if you turned off those ./configure flags for libtiff and rebuilt the deps would go away? that is, if they really are compile time options...