[GRASS-dev] problem with r.mapcalc in GRASS 7

[Barton Michael]

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.