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

[William Kyngesburye]

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

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

[Barton Michael]

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.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Glynn Clements]

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 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1020: Display of vector maps fails

[GRASS GIS]

#1020: Display of vector maps fails
--+-
 Reporter:  MilenaN   |   Owner:  grass-...@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  blocker   |   Milestone:  6.4.0 
   
Component:  Database  | Version:  6.4.0 RCs 
   
 Keywords:  wingrass, db.describe, wxGUI  |Platform:  MSWindows 7   
   
  Cpu:  x86-64|  
--+-

Comment(by glynn):

 Replying to [comment:18 martinl]:

 > Seems to also work in devbr6. When displaying archsites from spearfish60
 I am just getting some warnings
 >
 {{{
 G_spawn: unable to redirect descriptor 4
 G_spawn: unable to redirect descriptor 5
 }}}
 >
 > Any idea how it could be fixed. Thanks.

 Backport r40905.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] can not start grass82

[Martin Landa]

Hi,

2010/6/25 fire jotawski :
> i am using freebsd 8.0 and install grass62.  when i start using grass by
> grass62, i got this error message

6.2.* is too old. Consider updating at least to 6.4.0RC6 [1].

Martin

[1] http://grass.osgeo.org/download/software.php#g64x

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Barton Michael]

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 = oldmap*2"  [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










___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1020: Display of vector maps fails

[GRASS GIS]

#1020: Display of vector maps fails
--+-
 Reporter:  MilenaN   |   Owner:  grass-...@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  blocker   |   Milestone:  6.4.0 
   
Component:  Database  | Version:  6.4.0 RCs 
   
 Keywords:  wingrass, db.describe, wxGUI  |Platform:  MSWindows 7   
   
  Cpu:  x86-64|  
--+-

Comment(by martinl):

 Replying to [comment:17 martinl]:

 > Thanks! Seems to work, backported in r42654 to devbr6 (available for
 testing in the next daily build on http://josef.fsv.cvut.cz/wingrass).
 Martin

 Seems to also work in devbr6. When displaying archsites from spearfish60 I
 am just getting some warnings

 {{{
 G_spawn: unable to redirect descriptor 4
 G_spawn: unable to redirect descriptor 5
 }}}

 Any idea how it could be fixed. Thanks.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxnviz not compiling in GRASS 6.5 svn

[Martin Landa]

Hi,

2010/6/25 Barton Michael :
> I just updated from the CVS, did a make distclean, and compiled.
> wxnviz failed to compile with the error below.

wxNviz C++ component has been replaced in trunk by wxnviz.py. It will
be also done in devbr6 when ctypes will be backported. Please use till
this time trunk.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] wxnviz not compiling in GRASS 6.5 svn

[Barton Michael]

I just updated from the CVS, did a make distclean, and compiled. 

wxnviz failed to compile with the error below.

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



==  compile error =

Errors in:
/Users/cmbarton/grass_dev/grass65_dev/gui/wxpython/nviz
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Fri Jun 25 12:18:45 MST 2010
make: *** [default] Error 1
cmb-MBP:grass65_dev cmbarton$ cd 
/Users/cmbarton/grass_dev/grass65_dev/gui/wxpython/nviz
cmb-MBP:nviz cmbarton$ make
python setup.py build_ext --swig=/usr/bin/swig --swig-opts=-c++ 
--build-lib=OBJ.i386-apple-darwin10.4.0 --build-temp=OBJ.i386-apple-darwin10.4.0
running build_ext
building '_grass6_wxnviz' extension
swigging grass6_wxnviz.i to grass6_wxnviz_wrap.cpp
/usr/bin/swig -python -c++ -o grass6_wxnviz_wrap.cpp grass6_wxnviz.i
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall 
-Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe 
-DPACKAGE="grasslibs" -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ 
-D__WXMAC__ 
-I/Users/cmbarton/grass_dev/grass65_dev/dist.i386-apple-darwin10.4.0/include 
-I/Library/Frameworks/GDAL.framework/Versions/1.7/Headers 
-I/usr/local/lib/wxPython-unicode-2.8.10.1/lib/wx/include/mac-unicode-debug-2.8 
-I/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8 
-I/System/Library/Frameworks/OpenGL.framework/Headers 
-I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c 
change_view.cpp -o OBJ.i386-apple-darwin10.4.0/change_view.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC 
but not for C++
In file included from 
/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/glcanvas.h:4,
 from 
/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/glcanvas.h:60,
 from nviz.h:26,
 from change_view.cpp:15:
/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:49:
 warning: ‘AGLDrawable’ is deprecated (declared at 
/System/Library/Frameworks/AGL.framework/Headers/agl.h:48)
/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:53:
 warning: ‘AGLDrawable’ is deprecated (declared at 
/System/Library/Frameworks/AGL.framework/Headers/agl.h:48)
change_view.cpp: In member function ‘std::vector 
> Nviz::SetViewDefault()’:
change_view.cpp:56: error: cannot convert ‘float*’ to ‘double*’ for argument 
‘1’ to ‘int Nviz_get_exag_height(double*, double*, double*)’
change_view.cpp: In member function ‘int Nviz::SetView(float, float, float, 
float, float)’:
change_view.cpp:81: error: cannot convert ‘nv_data*’ to ‘double’ for argument 
‘1’ to ‘int Nviz_set_viewpoint_height(double)’
change_view.cpp:83: error: cannot convert ‘nv_data*’ to ‘double’ for argument 
‘1’ to ‘int Nviz_set_viewpoint_position(double, double)’
change_view.cpp:85: error: invalid conversion from ‘nv_data*’ to ‘int’
/Users/cmbarton/grass_dev/grass65_dev/dist.i386-apple-darwin10.4.0/include/grass/nviz.h:134:
 error: too many arguments to function ‘int Nviz_set_viewpoint_twist(int)’
change_view.cpp:85: error: at this point in file
change_view.cpp:87: error: invalid conversion from ‘nv_data*’ to ‘int’
/Users/cmbarton/grass_dev/grass65_dev/dist.i386-apple-darwin10.4.0/include/grass/nviz.h:133:
 error: too many arguments to function ‘int Nviz_set_viewpoint_persp(int)’
change_view.cpp:87: error: at this point in file
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC 
but not for C++
In file included from 
/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/glcanvas.h:4,
 from 
/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/glcanvas.h:60,
 from nviz.h:26,
 from change_view.cpp:15:
/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:49:
 warning: ‘AGLDrawable’ is deprecated (declared at 
/System/Library/Frameworks/AGL.framework/Headers/agl.h:48)
/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:53:
 warning: ‘AGLDrawable’ is deprecated (declared at 
/System/Library/Frameworks/AGL.framework/Headers/agl.h:48)
change_view.cpp: In member function ‘std::vector 
> Nviz::SetViewDefault()’:
change_view.cpp:56: error: cannot convert ‘float*’ to ‘double*’ for argument 
‘1’ to ‘int Nviz_get_exag_height(double*, double*, double*)’
change_view

[GRASS-dev] v.krige and variogram preview

[Anne Ghisla]

Hi devs,

the split of v.krige into script and GUI broke the variogram preview -
programmatically it was based on global variables, that worked when
the code was all in one script.
The point is that variogram preview needs to load data before hitting
"Run" button. AFAIK, GRASS modules usually collect parameters and then
run the appropriate command. I thought about creating a new module,
v.krige.variogram, and call it from v.krige GUI only to draw the
variogram and give the parameters back to v.krige. It could also be
run separately.
What do you think? Thanks in advance for suggestions.

regards
Anne
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1091: WinGrass7 + v.krige: rpy2 not installed + nightly Wingrass-build

[GRASS GIS]

#1091: WinGrass7 + v.krige: rpy2 not installed + nightly Wingrass-build
+---
 Reporter:  hellik  |   Owner:  martinl
 Type:  task|  Status:  assigned   
 Priority:  normal  |   Milestone:  7.0.0  
Component:  Packaging   | Version:  svn-trunk  
 Keywords:  wingrass, vkrige, rpy2  |Platform:  MSWindows Vista
  Cpu:  Unspecified |  
+---
Changes (by aghisla):

 * cc: aghisla (added)


-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] can not start grass82

[fire jotawski]

hi sirs,

i am using freebsd 8.0 and install grass62.  when i start using grass by
grass62, i got this error message

% grass62
Searching for web browser, but neither konqueror, nor mozilla, opera,
netscape found.

WELCOME TO GRASS  Version 6.2.3 2007

   1) Have at your side all available GRASS tutorials

   2) When working on your location, the following materials
  are extremely useful:
  - A topo map of your area
  - Current catalog of available computer maps

   3) Check the GRASS webpages for feedback mailinglists and more:
  http://grass.itc.it/
  http://grass.ibiblio.edu/

Hit RETURN to continue

Starting GRASS ...
Error in startup script: list element in quotes followed by "à¸à¸³" instead
of space
while executing
"foreach i [exec ls -a [exec pwd]] {
if { [string compare $i "."] != 0 &&  [string compare $i ".."] != 0
&&  [file isdirectory $i] } {
 ..."
(procedure "gisSetWindow" line 244)
invoked from within
"gisSetWindow"
invoked from within
"if { [searchGISRC $gisrc_name] } {
   gisSetWindow
}"
(file "/usr/local/grass/etc/gis_set.tcl" line 903)
Error in Tcl/Tk startup. If necessary, please
report this error to the GRASS developers.
Switching to text mode now.
Hit RETURN to continue...

how to overcome this errors.  many thanks in advance for any answers.

with best regards,
jotawski


-- 
มะขาม คินเดินดน
มะไฟ ฅนเหลิงฟ้า
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev