I just tried r.external for the first time, and while r.external successfully created the link raster, any attempt to access the raster data results in the error "Unable to load GDAL library".
Looking at where that error comes from, I find lib/gis/gdal.c, where it's trying to dynamically load the GDAL library. Looks like it's hardwired that way in the lib/gis makefile:
GDAL_DYNAMIC = 1
Is it safe to override this, so that libgis static-links GDAL? It looks like the makefile and gdal.c are setup to toggle such static linking. Shouldn't there be a configure option for this (assuming it works)?
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy
William Kyngesburye wrote:
I just tried r.external for the first time, and while r.external
successfully created the link raster, any attempt to access the
raster data results in the error "Unable to load GDAL library".
Looking at where that error comes from, I find lib/gis/gdal.c, where
it's trying to dynamically load the GDAL library. Looks like it's
hardwired that way in the lib/gis makefile:
GDAL_DYNAMIC = 1
Is it safe to override this, so that libgis static-links GDAL?
Probably. Doing so does, however, mean that if there's an issue with
GDAL, most of GRASS stops working.
Also, GDAL is written in C++, so any constructors for static variables
get executed at startup (i.e. when the library is loaded). If any of
those constructors do anything "problematic", compile-time linking
means that it will happen whenever you run anything which uses libgis,
regardless of whether it accesses a linked map.
In 7.0, the GDAL support is in the raster library rather than libgis,
which limits the scope of any such issues.
It
looks like the makefile and gdal.c are setup to toggle such static
linking. Shouldn't there be a configure option for this (assuming it
works)?
Possibly.
--
Glynn Clements <glynn@gclements.plus.com>