<div dir="ltr">We have resolved the  issue.<div><br></div><div>My problem statement was misleading. Our program was not having trouble finding a library, but rather the libgeotiff<span style="font-size:13px"> library was having trouble finding its data files, which came out in opensnoop as failures to open:</span></div><div><br></div><div><div style="font-size:13px"><div>1698751227   2095 MARPLOT_server  39 /Library/Frameworks/UnixImageIO.framework/Versions/E/Resources/epsg_csv/pcs.override.csv </div><div>1698751227   2095 MARPLOT_server  39 /Library/Frameworks/UnixImageIO.framework/Versions/E/Resources/epsg_csv/pcs.csv </div><div>1698751227   2095 MARPLOT_server  39 /Library/Frameworks/UnixImageIO.framework/Versions/E/Resources/epsg_csv/projop_wparm.csv </div><div><br></div><div>So I learned that in the build of UnixImageIO.framework, in buildfw-uiio.sh, it uses a hard-coded path to /Library/Frameworks as the prefix for the --data-dir parameter used in building geotiff, which becomes CSV_DATA_DIR in geotiff's cpl_csv_c. But that file also shows that the environment variable GEOTIFF_CSV can be defined to override CSV_DATA_DIR, so we are doing that now with a setenv() call, and it works.</div><div><br></div><div>So for users like me who want to bundle GDAL into a standalone app, it would help include a note about this gotcha, perhaps in the UnixImageIO section of your "Unix Compatibility Frameworks" page.</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 26, 2015 at 8:17 PM, William Kyngesburye <span dir="ltr"><<a href="mailto:woklist@kyngchaos.com" target="_blank">woklist@kyngchaos.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My email should be in the GDAL installer readme.<br>
<br>
Anyways, yes, the whole batch of frameworks is set up for absolue paths.  So not only does GDAL reference UnixImageIO (and SQLite3), when you compile an app linked to them, it will also link absolute paths to the frameworks.<br>
<br>
The standard way to change this in your app and in any bundled frameworks is to use install_name_tool with the -change option and a special relative path keyword, @loader_path:<br>
<br>
install_name_tool -change /original/path @loader_path/relative/path /path/to/bundled/framework/binary<br>
<br>
/original/path will be the /Library/Frameworks path to the binary file of the framework.<br>
<br>
the relative path is relative from the binary file in the framework, so you will need to back out with a few ../<br>
<br>
Of course, your app should know how to redirect GDAL to the bundled copies of its support files, or it will try to find them in the compiled in /Library/Frameworks path.  The UnixImageIO framework also has support files for the geotiff library that will have to be redirected if used.<br>
<br>
On Jan 26, 2015, at 6:07 PM, Michael Katz - NOAA Affiliate <<a href="mailto:michael.katz@noaa.gov">michael.katz@noaa.gov</a>> wrote:<br>
<br>
> I am using the GDAL 1.11 Complete build for Mac found here: <a href="http://www.kyngchaos.com/software/frameworks" target="_blank">http://www.kyngchaos.com/software/frameworks</a>.<br>
><br>
> I am installing my .app bundle in /Applications (or rather the user is installing it there via a drag-and-drop .dmg), and I don't want the user to have to install anything to /Library/Frameworks.<br>
><br>
> However, it appears that something inside the GDAL library is referencing /Library/Frameworks/UnixImageIO.framework as an absolute path, and I haven't been able to find a way to tell it to reference that framework from its location within my .app bundle instead.<br>
><br>
> The result is that certain files, such as .tif files, are not handled correctly (e.g., I cannot get the bounding world rect of a georeferenced .tif file when /Library/Frameworks/UnixImageIO.framework is not present, but can get it when /Library/Frameworks/UnixImageIO.framework is present).<br>
><br>
> I looked at the QGIS installer, but that requires you to install GDAL plus UnixImageIO to /Library/Frameworks explicitly, so that didn't help.<br>
><br>
> I understand this Mac build of GDAL is done by William Kyngesburye, and is not part of the official GDAL build, but I couldn't find a way to get in touch with Kyngesburye directly and I thought someone on this list might have faced this problem.<br>
><br>
> Thanks for any help.<br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
-----<br>
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com><br>
<a href="http://www.kyngchaos.com/" target="_blank">http://www.kyngchaos.com/</a><br>
<br>
Earth: "Mostly harmless"<br>
<br>
- revised entry in the HitchHiker's Guide to the Galaxy<br>
<br>
<br>
</blockquote></div><br></div></div>