[GRASS-user] addons installation under GRASS 7.0-svn

Rhot · August 11, 2010, 10:13am

Hello!
I've got a problem with installing of any addon to grass 7.0-svn (Ubuntu 9.10). Particularly, while installing module i.landsat.acca, I got the following errors.

>>
rhot@rhot-workstation:~/Dl/i.landsat.acca$ LANGUAGE=en.US.UTF-8 make MODULE_TOPDIR=/usr/local/grass-7.0.svn/
: && gcc -L/home/rhot/Dl/grass_svn/grass_trunk/dist.i686-pc-linux-gnu/lib -L/home/rhot/Dl/grass_svn/grass_trunk/dist.i686-pc-linux-gnu/lib -Wl,--export-dynamic -Wl,-rpath-link,/home/rhot/Dl/grass_svn/grass_trunk/dist.i686-pc-linux-gnu/lib -o /home/rhot/Dl/grass_svn/grass_trunk/dist.i686-pc-linux-gnu/bin/i.landsat.acca OBJ.i686-pc-linux-gnu/algorithm.o OBJ.i686-pc-linux-gnu/main.o OBJ.i686-pc-linux-gnu/tools.o -lgrass_gis.7.0.svn -lm OBJ.i686-pc-linux-gnu/algorithm.o: In function `acca_second':
/home/rhot/Dl/i.landsat.acca/algorithm.c:361: undefined reference to `G_find_cell2'
/home/rhot/Dl/i.landsat.acca/algorithm.c:364: undefined reference to `G_allocate_raster_buf'
/home/rhot/Dl/i.landsat.acca/algorithm.c:365: undefined reference to `G_open_cell_old'
/home/rhot/Dl/i.landsat.acca/algorithm.c:370: undefined reference to `G_allocate_raster_buf'
/home/rhot/Dl/i.landsat.acca/algorithm.c:371: undefined reference to `G_open_raster_new'
/home/rhot/Dl/i.landsat.acca/algorithm.c:379: undefined reference to `G_window_rows'
/home/rhot/Dl/i.landsat.acca/algorithm.c:380: undefined reference to `G_window_cols'
/home/rhot/Dl/i.landsat.acca/algorithm.c:388: undefined reference to `G_get_d_raster_row'
/home/rhot/Dl/i.landsat.acca/algorithm.c:390: undefined reference to `G_get_c_raster_row'
/home/rhot/Dl/i.landsat.acca/algorithm.c:395: undefined reference to `G_is_c_null_value'
/home/rhot/Dl/i.landsat.acca/algorithm.c:409: undefined reference to `G_set_c_null_value'
/home/rhot/Dl/i.landsat.acca/algorithm.c:430: undefined reference to `G_put_raster_row'
/home/rhot/Dl/i.landsat.acca/algorithm.c:439: undefined reference to `G_close_cell'
/home/rhot/Dl/i.landsat.acca/algorithm.c:442: undefined reference to `G_close_cell'
OBJ.i686-pc-linux-gnu/algorithm.o: In function `acca_first':
/home/rhot/Dl/i.landsat.acca/algorithm.c:220: undefined reference to `G_allocate_raster_buf'
/home/rhot/Dl/i.landsat.acca/algorithm.c:221: undefined reference to `G_open_raster_new'
/home/rhot/Dl/i.landsat.acca/algorithm.c:232: undefined reference to `G_window_rows'
/home/rhot/Dl/i.landsat.acca/algorithm.c:233: undefined reference to `G_window_cols'
/home/rhot/Dl/i.landsat.acca/algorithm.c:243: undefined reference to `G_get_d_raster_row'
/home/rhot/Dl/i.landsat.acca/algorithm.c:252: undefined reference to `G_is_d_null_value'
/home/rhot/Dl/i.landsat.acca/algorithm.c:329: undefined reference to `G_set_c_null_value'
/home/rhot/Dl/i.landsat.acca/algorithm.c:336: undefined reference to `G_put_raster_row'
/home/rhot/Dl/i.landsat.acca/algorithm.c:344: undefined reference to `G_close_cell'
OBJ.i686-pc-linux-gnu/main.o: In function `check_raster':
/home/rhot/Dl/i.landsat.acca/main.c:56: undefined reference to `G_find_cell2'
/home/rhot/Dl/i.landsat.acca/main.c:65: undefined reference to `G_open_cell_old'
/home/rhot/Dl/i.landsat.acca/main.c:69: undefined reference to `G_get_cellhd'
/home/rhot/Dl/i.landsat.acca/main.c:77: undefined reference to `G_raster_map_type'
OBJ.i686-pc-linux-gnu/main.o: In function `main':
/home/rhot/Dl/i.landsat.acca/main.c:169: undefined reference to `G_allocate_raster_buf'
/home/rhot/Dl/i.landsat.acca/main.c:195: undefined reference to `G_close_cell'
/home/rhot/Dl/i.landsat.acca/main.c:202: undefined reference to `G_short_history'
/home/rhot/Dl/i.landsat.acca/main.c:203: undefined reference to `G_command_history'
/home/rhot/Dl/i.landsat.acca/main.c:204: undefined reference to `G_write_history'
OBJ.i686-pc-linux-gnu/tools.o: In function `pval':
/home/rhot/Dl/i.landsat.acca/tools.c:125: undefined reference to `G_is_c_null_value'
OBJ.i686-pc-linux-gnu/tools.o: In function `filter_holes':
/home/rhot/Dl/i.landsat.acca/tools.c:141: undefined reference to `G_window_rows'
/home/rhot/Dl/i.landsat.acca/tools.c:142: undefined reference to `G_window_cols'
/home/rhot/Dl/i.landsat.acca/tools.c:148: undefined reference to `G_find_cell2'
/home/rhot/Dl/i.landsat.acca/tools.c:151: undefined reference to `G_allocate_raster_buf'
/home/rhot/Dl/i.landsat.acca/tools.c:152: undefined reference to `G_allocate_raster_buf'
/home/rhot/Dl/i.landsat.acca/tools.c:153: undefined reference to `G_allocate_raster_buf'
/home/rhot/Dl/i.landsat.acca/tools.c:154: undefined reference to `G_open_cell_old'
/home/rhot/Dl/i.landsat.acca/tools.c:159: undefined reference to `G_allocate_raster_buf'
/home/rhot/Dl/i.landsat.acca/tools.c:160: undefined reference to `G_open_raster_new'
/home/rhot/Dl/i.landsat.acca/tools.c:175: undefined reference to `G_get_c_raster_row'
/home/rhot/Dl/i.landsat.acca/tools.c:178: undefined reference to `G_get_c_raster_row'
/home/rhot/Dl/i.landsat.acca/tools.c:184: undefined reference to `G_get_c_raster_row'
/home/rhot/Dl/i.landsat.acca/tools.c:325: undefined reference to `G_set_c_null_value'
/home/rhot/Dl/i.landsat.acca/tools.c:328: undefined reference to `G_put_raster_row'
/home/rhot/Dl/i.landsat.acca/tools.c:337: undefined reference to `G_close_cell'
/home/rhot/Dl/i.landsat.acca/tools.c:340: undefined reference to `G_close_cell'
collect2: ld returned 1 exit status
make: *** [/home/rhot/Dl/grass_svn/grass_trunk/dist.i686-pc-linux-gnu/bin/i.landsat.acca] Error 1
<<

There is a 6.4.0-svn installation on my PC as well. And installing addons on it worked very well. I guess there is something new in grass7.0, even about installing modules.
Can anyone help me with this issue please?

Best wishes,
Vladimir.

martinl · August 11, 2010, 10:17am

Hi,

2010/8/11 Rhot <rhot@rambler.ru>:

Hello!
I've got a problem with installing of any addon to grass 7.0-svn (Ubuntu
9.10). Particularly, while installing module i.landsat.acca, I got the
following errors.

you need to update the code to use raster library which has been
introduced in GRASS 7 a few months ago [1].

Martin

[1] http://trac.osgeo.org/grass/wiki/Grass7/RasterLib

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Rhot · August 11, 2010, 12:46pm

Martin Landa пишет:

Hi,

2010/8/11 Rhot <rhot@rambler.ru>:

Hello!
I've got a problem with installing of any addon to grass 7.0-svn (Ubuntu
9.10). Particularly, while installing module i.landsat.acca, I got the
following errors.

you need to update the code to use raster library which has been
introduced in GRASS 7 a few months ago [1].

Martin

[1] http://trac.osgeo.org/grass/wiki/Grass7/RasterLib

Maybe you mean 'to update the code of the module'?? But how? I am not a programmer. I'm just a GIS specialist trying to use newest grass-7.0 with addons written for grass-6.x as grass-wiki says.

--
Vladimir.

martinl · August 13, 2010, 11:17am

Hi,

2010/8/11 Rhot <rhot@rambler.ru>:

Maybe you mean 'to update the code of the module'?? But how? I am not a
programmer. I'm just a GIS specialist trying to use newest grass-7.0 with
addons written for grass-6.x as grass-wiki says.

I have committed patch to SVN [1]. g.extension module [2] has been
updated in this regard, it means that the module applies grass7.patch
if available.

g.extension ext=i.landsat.acca

should work now.

Martin

[1] http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.landsat.acca/grass7.patch?rev=43089
[2] http://grass.osgeo.org/grass70/manuals/html70_user/g.extension.html

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Rhot · August 13, 2010, 12:51pm

Martin Landa пишет:

Hi,

2010/8/11 Rhot <rhot@rambler.ru>:

Maybe you mean 'to update the code of the module'?? But how? I am not a
programmer. I'm just a GIS specialist trying to use newest grass-7.0 with
addons written for grass-6.x as grass-wiki says.

I have committed patch to SVN [1]. g.extension module [2] has been
updated in this regard, it means that the module applies grass7.patch
if available.

g.extension ext=i.landsat.acca

should work now.

Martin

[1] http://trac.osgeo.org/grass/browser/grass-addons/imagery/i.landsat.acca/grass7.patch?rev=43089
[2] http://grass.osgeo.org/grass70/manuals/html70_user/g.extension.html

Thanks a lot Martin!
I downloaded svn code again and reinstalled grass-7.0svn. It works perfectly!
I understood, regarding to that new raster library in grass70 absolutely all addons in svn repo will be worthless in grass70 until they'll be updated. Is it so?
I use i.landsat.acca module always with i.landsat.toar module since the i.landsat.acca module needs files created with i.landsat.toar.

Vladimir.

Hamish · August 13, 2010, 8:40pm

Rhot wrote:

>> But how? I am not a programmer. I'm just a GIS
>> specialist trying to use newest grass-7.0

unless you are a programmer helping to develop 7.0, you
probably shouldn't be using it. (yet)

Use 6.4 instead.

I understood, regarding to that new raster library in
grass70 absolutely all addons in svn repo will be
worthless in grass70 until they'll be updated. Is it so?

perhaps not absolutely all, but between the C lib changes
and the (I hope hope temporary) removal of shell script
support, it is safe to say that most will need some
porting work.

Hamish

Rhot · August 15, 2010, 3:09pm

Hamish пишет:

Rhot wrote:


But how? I am not a programmer. I'm just a GIS
specialist trying to use newest grass-7.0

unless you are a programmer helping to develop 7.0, you
probably shouldn't be using it. (yet)

Use 6.4 instead.

I understood, regarding to that new raster library in
grass70 absolutely all addons in svn repo will be
worthless in grass70 until they'll be updated. Is it so?

perhaps not absolutely all, but between the C lib changes
and the (I hope hope temporary) removal of shell script
support, it is safe to say that most will need some
porting work.

Hamish

I see. Well, thank you for making it clear for me. Then it will be more compilation work for me in grass-6.4 that I'm using now.

Cheers,
Vladimir.

Nikos_Alexandris1 · August 15, 2010, 3:23pm

Rhot wrote:

> I understood, regarding to that new raster library in
> grass70 absolutely all addons in svn repo will be
> worthless in grass70 until they'll be updated. Is it so?

Hamish:

perhaps not absolutely all, but between the C lib changes
and the (I hope hope temporary) removal of shell script
support, it is safe to say that most will need some
porting work.

Oh... :-O. Shell script(ing) ability completly removed in grass7x?

@devs: please keep the very minimum of shell script support if possible. Often
it is so much faster to work in the shell...

Nikos

Glynn_Clements1 · August 15, 2010, 4:48pm

Nikos Alexandris wrote:

> perhaps not absolutely all, but between the C lib changes
> and the (I hope hope temporary) removal of shell script
> support, it is safe to say that most will need some
> porting work.

Oh... :-O. Shell script(ing) ability completly removed in grass7x?

You can still run GRASS commands from shell scripts, and you can still
use g.parser in shell scripts.

The only thing that has changed is that the build system no longer has
rules for shell scripts. If you want to write a Makefile to install a
shell script, you can't rely upon Script.make or ScriptRules.make, as
they assume that all scripts are Python (i.e. the source file must
have a .py extension, and the installed script will have a .py
extension on Windows).

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

neteler · August 16, 2010, 10:17am

On Sun, Aug 15, 2010 at 6:48 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Nikos Alexandris wrote:

> perhaps not absolutely all, but between the C lib changes
> and the (I hope hope temporary) removal of shell script
> support, it is safe to say that most will need some
> porting work.

Oh... :-O. Shell script(ing) ability completly removed in grass7x?

You can still run GRASS commands from shell scripts, and you can still
use g.parser in shell scripts.

I have tried but get

GRASS 7.0.svn (nc_spm_08): > sh i.fusion.his
sh: i.fusion.his: command not found
Traceback (most recent call last):
  File "/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/etc/gui/wxpython/gui_modules/menuform.py",
line 2219, in <module>
    task = grassTask(cmd[0])
  File "/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/etc/gui/wxpython/gui_modules/menuform.py",
line 371, in __init__
    processTask(tree = etree.fromstring(getInterfaceDescription(grassModule)),
  File "/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/etc/gui/wxpython/gui_modules/menuform.py",
line 1994, in getInterfaceDescription
    raise IOError, _("Unable to fetch interface description for
command '%s'.") % cmd
IOError: Unable to fetch interface description for command 'i.fusion.his'.

Markus

Glynn_Clements1 · August 16, 2010, 9:59pm

Markus Neteler wrote:

>> > perhaps not absolutely all, but between the C lib changes
>> > and the (I hope hope temporary) removal of shell script
>> > support, it is safe to say that most will need some
>> > porting work.
>>
>> Oh... :-O. Shell script(ing) ability completly removed in grass7x?
>
> You can still run GRASS commands from shell scripts, and you can still
> use g.parser in shell scripts.

I have tried but get

GRASS 7.0.svn (nc_spm_08): > sh i.fusion.his
sh: i.fusion.his: command not found

Does it have the execute bit set? If it doesn't, g.parser can't
execute it. That has always been the case; it isn't specific to 7.0.

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

neteler · August 16, 2010, 10:55pm

On Mon, Aug 16, 2010 at 11:59 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

>> > perhaps not absolutely all, but between the C lib changes
>> > and the (I hope hope temporary) removal of shell script
>> > support, it is safe to say that most will need some
>> > porting work.
>>
>> Oh... :-O. Shell script(ing) ability completly removed in grass7x?
>
> You can still run GRASS commands from shell scripts, and you can still
> use g.parser in shell scripts.

I have tried but get

GRASS 7.0.svn (nc_spm_08): > sh i.fusion.his
sh: i.fusion.his: command not found

Does it have the execute bit set?

Yes.

If it doesn't, g.parser can't
execute it. That has always been the case; it isn't specific to 7.0.

ls -la i.fusion.his
-rwxr-xr-x 1 neteler neteler 3867 2009-09-29 21:36 i.fusion.his*

The problem was that it wasn't in the search path.
Sorry for the noise (maybe there is a way to catch this?).

Markus

Glynn_Clements1 · August 18, 2010, 5:35am

Markus Neteler wrote:

>> GRASS 7.0.svn (nc_spm_08): > sh i.fusion.his
>> sh: i.fusion.his: command not found
>
> Does it have the execute bit set?

Yes.

> If it doesn't, g.parser can't
> execute it. That has always been the case; it isn't specific to 7.0.

ls -la i.fusion.his
-rwxr-xr-x 1 neteler neteler 3867 2009-09-29 21:36 i.fusion.his*

The problem was that it wasn't in the search path.

I thought of mentioning this, then concluded that it shouldn't make a
difference. But it turns out that it matters if GRASS_GUI is set to
"wxpython".

If you "execute" a script by typing its name, it must be in $PATH. But
if you execute "sh" with the script filename as an argument, the shell
will just [f]open() it, and the normal rules apply (i.e. any path not
starting with a "/" is relative to the current directory).

And when g.parser invokes the script, it uses execl(), which doesn't
use the path.

AFAICT, the problem is when g.parser uses G_gui_wx(). Whereas
G_gui_tcltk() invokes gui.tcl and feeds it a description on its stdin,
G_gui_wx() invokes menuform.py with the command line, and G_gui_wx()
re-invokes the script with the --interface-description flag. The
script is exceuted using os.popen(), which uses /bin/sh, which uses
$PATH, hence the error.

So if you run the script with arguments (so that no dialog is
generated), or if GRASS_GUI is set to "tcltk", I think that it should
work regardless of whether the script is in $PATH.

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