GDAL is in a "framework" on Mac OS X. That is, it is in ... /Library/Frameworks/GDAL.framework
It is not in a path, but is explicitly linked in configure with ... --with-gdal=/Library/Frameworks/GDAL.framework/ Is this no longer a valid argument? Michael ____________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jun 25, 2010, at 6:34 PM, Glynn Clements wrote: > > Barton Michael wrote: > >> I'm not sure if this is a general issues or something specific to my OS X >> 10.6.4 build. >> >> I just updated and compiled trunk. >> >> When I try to use r.mapcalc, I get the following error: ERROR: Unable to >> load GDAL library > > This is related to the r.external support. GDAL should only be loaded > on demand, i.e. if you try to open or create a "linked" map. > > You can eliminate the problem by unsetting GDAL_DYNAMIC, e.g. > > make GDAL_DYNAMIC= ... > > This causes libraster to be linked against GDAL directly, rather than > loading it dynamically with dlopen(). However, this might cause other > problems. GDAL is written in C++, which means that simply loading it > will cause constructors to be executed. > > FWIW, the list of candidate filenames is: > > libgdal.1.1.so > gdal.1.0.so > gdal.so.1.0 > libgdal.so.1 > libgdal.so > > If GDAL is called something else, or isn't found by the loader (for > whatever reason), you'll get the error you describe. On Linux, the > library needs to either be in $LD_LIBRARY_PATH, or in the cache > created by ldconfig. I'm not familiar with the mechanisms used on OSX. _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
