On Jun 25, 2010, at 8: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 > These won't work on OS X for either a Unix build of GDAL, where all libraries are named *[.x].dylib, or a framework build, where it would be GDAL.framework/Versions/x.y/GDAL (x.y major.minor version, ie currently 1.7).
Also, the above (probably) won't be tried anyways - __unix__ is not a standard GCC define on OSX (I thought it was, but couldn't find any reference to it). __APPLE__ is the one to use for an OSX test. > 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. > OS X uses DYLD_LIBRARY_PATH, otherwise it works the same, for unix-style libraries. There is also a DYLD_FRAMEWORK_PATH that works similarly for frameworks. But, according to the dlopen manpage, DYLD_FRAMEWORK_PATH doesn't work for dlopen()'d frameworks, only DYLD_LIBRARY_PATH works for dlopen()'d unix-style libraries (it only explicitly mentions DYLD_LIBRARY_PATH), assuming OSX style library names are used. So, compiling with GDAL_DYNAMIC unset is really the only option. Unless some messy framework search logic is added to the dynamic loading. On Jun 25, 2010, at 10:59 PM, Barton Michael wrote: > I tried this and got the same error. make clean first? ----- William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
