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

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

I’m also not sure how to use the new syntax, as the manual is lacking in examples of the use of the “expression” argument.

Old mapcalc:
r.mapcalc ‘newmap=oldmap*2’

New mapcalc:
r.mapcalc “newmap = oldmap2" [CORRECT? This gives the gdal error]
r.mapcalc file=newmap expression="oldmap
2” [This gives a parse error]

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

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.

I'm also not sure how to use the new syntax, as the manual is
lacking in examples of the use of the "expression" argument.

Old mapcalc:
r.mapcalc 'newmap=oldmap*2'

New mapcalc:
r.mapcalc "newmap = oldmap*2" [CORRECT? This gives the gdal error]
r.mapcalc file=newmap expression="oldmap*2" [This gives a parse error]

The expression= option is the first option, so you don't need to
specify expression= explicitly *provided* that the value won't itself
be mistaken for an option.

"newmap=oldmap*2" will be mistaken for an attempt to specify the
(non-existent) newmap= option, resulting in an error. Placing a space
before or after the "=" sign will prevent this, so the "CORRECT?"
example above works (at least so far as the parser is concerned).

For maximum compatibility when invoking r.mapcalc, use e.g.:

  r.mapcalc "outmap = inmap" # works with both 6.x and 7.0

rather than:

  r.mapcalc expr="outmap = inmap" # won't work with 6.x
  r.mapcalc "outmap=inmap" # won't work with 7.0
  r.mapcalc outmap = inmap # won't work with 7.0

The file= option is used to specify a file containing r.mapcalc
expressions (file=- reads from stdin), so:

  r.mapcalc file=foo

is equivalent to:

  r.mapcalc < foo
or:
  cat foo | r.mapcalc

except that file= is more GUI-friendly.

If you specify both file= and expression=, file= takes precedence[1].
As "newmap" presumably doesn't contain valid r.mapcalc expressions,
your last example results in a parse error.

If you specify neither file= nor expression=, "file=-" (i.e. read
expressions from stdin) is used, for compatibility with previous
versions.

[1] Fixed in r42659; using both expression= and file= now generates an
error.

--
Glynn Clements <glynn@gclements.plus.com>

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.

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= ...

I tried this and got the same error.

Michael

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.

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

On Jun 25, 2010, at 10:07 PM, William Kyngesburye wrote:

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/

I just did an svn update, make distclean, and make GDAL_DYNAMIC=

There has been an update to r.mapcalc

Now I get a different error

GRASS 7.0.svn (Spearfish60_test):~ > r.mapcalc "newmap2 = elevation.dem*2"
ERROR 1: TIFFOpen:/Users/Shared/grassdata/Spearfish60_test/PERMANENT/gdal/newmap2: Not a directory
ERROR: Unable to create <newmap2> dataset using <GTiff> driver

Michael

Barton Michael wrote:

I just did an svn update, make distclean, and make GDAL_DYNAMIC=

There has been an update to r.mapcalc

That was r42659, which generates an error if you use both expression=
and file=. It's unrelated to the GDAL issues (which are in lib/raster
rather than r.mapcalc per se).

Now I get a different error

GRASS 7.0.svn (Spearfish60_test):~ > r.mapcalc "newmap2 = elevation.dem*2"
ERROR 1: TIFFOpen:/Users/Shared/grassdata/Spearfish60_test/PERMANENT/gdal/newmap2: Not a directory
ERROR: Unable to create <newmap2> dataset using <GTiff> driver

The error indicates that you have have enabled output via GDAL
(r.external.out). Use "r.external.out -r" to revert to native output,
or use "r.external.out -p" to check your settings.

If you want TIFF output, you should probably set the extension to
".tif" or ".tiff" ("r.external.out ... extension=.tif").

--
Glynn Clements <glynn@gclements.plus.com>

On Jun 26, 2010, at 4:23 PM, Glynn Clements wrote:

Now I get a different error

GRASS 7.0.svn (Spearfish60_test):~ > r.mapcalc "newmap2 = elevation.dem*2"
ERROR 1: TIFFOpen:/Users/Shared/grassdata/Spearfish60_test/PERMANENT/gdal/newmap2: Not a directory
ERROR: Unable to create <newmap2> dataset using <GTiff> driver

The error indicates that you have have enabled output via GDAL
(r.external.out). Use "r.external.out -r" to revert to native output,
or use "r.external.out -p" to check your settings.

If you want TIFF output, you should probably set the extension to
".tif" or ".tiff" ("r.external.out ... extension=.tif").

That did the trick. I didn't know r.external.out was enabled. I must have enabled it in previous versions to test. But apparently it was not working correctly. Maybe I need to try it again and check the settings.

Michael