[GRASS-user] LSMetrics - addon development

GRASS GRASS user
1

Dear list,

We have been developing a python application called LSMetrics to calculate landscape metrics for environmental management and ecological research. All functions/metrics use GRASS modules in the process of calculation. More information here:
https://github.com/LEEClab/LS_METRICS/wiki

Basically we have several python functions, each of which calculates a different metric. All of them are then called by a single function that can coordinate the calculation of several metrics for several maps in a row.
Currently the metrics can be calculated for input maps using a grafical interface (we call it from the GRASS shell using “python LS_metrics_v1_0_0.py”) or by calling python shell from the GRASS shell and then using python scripting to call the functions (importing functions and then calling them directly). We wish to transform these function into one (or more than one) grass addon.

Then I have two questions:

  • Do you think it would be better to build a single addon (e.g. called r.ls.metrics) so that each metrics is defined by a parameter (e.g. method = “patch_size”, “fragment_size”, “structural connectivity” …), or rather a set of addons, each one corresponding to a single landscape metrics (e.g. r.ls.patch_size, r.ls.fragment_size, …)?

  • Also, I have looked on how to build the addon in GRASS help pages but I am not sure about some details. Can you send me some references to ease that process?

Thanks a lot.
Below you can find more information regarding the metrics.
Best
Bernardo Niebuhr

Metrics calculated:
Metrics related to structural connectivity:

  • patch size
  • fragment size (excludes corridors with a given edge depth)
  • structural connectivity
  • proportion of habitat (within a window around each pixel)
    Metrics related to functional connectivity
  • functionally connected area (considering the capacity of organisms to cross gaps between habitat patches)
  • functional connectivity
    Metrics related to habitat edges
  • distance from edges
  • clasisfication edge/core/matrix (considering a given edge depth)
  • proportion of edge and core (within a window around each pixel)
    Metrics of landscape diversity
    (we are currently using the r.diversity add on to calculate that)
2

Dear Bernardo,

On 07/02/18 14:55, Bernardo Santos wrote:

Dear list,

We have been developing a python application called LSMetrics to calculate landscape metrics for environmental management and ecological research. All functions/metrics use GRASS modules in the process of calculation. More information here:
https://github.com/LEEClab/LS_METRICS/wiki

Great, thanks !

Out of curiosity: could you maybe explain how this application compares to the existing r.li suite of modules in GRASS core (https://grass.osgeo.org/grass74/manuals/r.li.html) and the r.pi suite of modules in GRASS addons (there seems to be a problem with building the manual pages, but you can get an idea by looking at the description.html file here: https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.pi) ? I am no expert in the field of landscape metrics and am just wondering how this all fits into the picture.

Basically we have several python functions, each of which calculates a different metric. All of them are then called by a single function that can coordinate the calculation of several metrics for several maps in a row.
Currently the metrics can be calculated for input maps using a grafical interface (we call it from the GRASS shell using "python LS_metrics_v1_0_0.py") or by calling python shell from the GRASS shell and then using python scripting to call the functions (importing functions and then calling them directly). We wish to transform these function into one (or more than one) grass addon.

Then I have two questions:
- Do you think it would be better to build a single addon (e.g. called r.ls.metrics) so that each metrics is defined by a parameter (e.g. method = "patch_size", "fragment_size", "structural connectivity" ...), or rather a set of addons, each one corresponding to a single landscape metrics (e.g. r.ls.patch_size, r.ls.fragment_size, ...)?

The other two suites have gone for separate modules for each metric. I'm not sure what the rationale was behind that choice, but I guess we should try to be consistent across similar module suites.

- Also, I have looked on how to build the addon in GRASS help pages but I am not sure about some details. Can you send me some references to ease that process?

The basic idea for a module for addons is to create a directory with the source file(s), the html file for the manual page and a Makefile.

Please follow the general submitting rules as explained at https://trac.osgeo.org/grass/wiki/Submitting.

To get an idea of the structure of a suite of modules in Addons, you could look at the recently added r.sentinel tools: https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.sentinel

Moritz

3

Dear Moritz,

thanks for the answer and the examples.
I’ll try to put the functions and files in this format and test them like that.
I am not sure how to build these makefile files but I’ll try to follow the patterns I find in the other examples of modules.
Once this is done, I’ll post it here.

Which GRASS version I should use to do that?

Regarding the comparison with the other GRASS tools, LSMetrics is complementary to many of the functions the r.li suite offers. I still could not test r.pi since I had some trouble installing it, but I’ll try it again so that I can compare both packages. I believe they are also somehow complementary in many of the functions.

Best,
Bernardo

Em quarta-feira, 7 de fevereiro de 2018 13:15:03 BRST, Moritz Lennert mlennert@club.worldonline.be escreveu:

Dear Bernardo,

On 07/02/18 14:55, Bernardo Santos wrote:

Dear list,

We have been developing a python application called LSMetrics to
calculate landscape metrics for environmental management and ecological
research. All functions/metrics use GRASS modules in the process of
calculation. More information here:
https://github.com/LEEClab/LS_METRICS/wiki

Great, thanks !

Out of curiosity: could you maybe explain how this application compares
to the existing r.li suite of modules in GRASS core
(https://grass.osgeo.org/grass74/manuals/r.li.html) and the r.pi suite
of modules in GRASS addons (there seems to be a problem with building
the manual pages, but you can get an idea by looking at the
description.html file here:
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.pi) ?
I am no expert in the field of landscape metrics and am just wondering
how this all fits into the picture.

Basically we have several python functions, each of which calculates a
different metric. All of them are then called by a single function that
can coordinate the calculation of several metrics for several maps in a row.
Currently the metrics can be calculated for input maps using a grafical
interface (we call it from the GRASS shell using “python
LS_metrics_v1_0_0.py”) or by calling python shell from the GRASS shell
and then using python scripting to call the functions (importing
functions and then calling them directly). We wish to transform these
function into one (or more than one) grass addon.

Then I have two questions:

  • Do you think it would be better to build a single addon (e.g. called
    r.ls.metrics) so that each metrics is defined by a parameter (e.g.
    method = “patch_size”, “fragment_size”, “structural connectivity” …),
    or rather a set of addons, each one corresponding to a single landscape
    metrics (e.g. r.ls.patch_size, r.ls.fragment_size, …)?

The other two suites have gone for separate modules for each metric. I’m
not sure what the rationale was behind that choice, but I guess we
should try to be consistent across similar module suites.

  • Also, I have looked on how to build the addon in GRASS help pages but
    I am not sure about some details. Can you send me some references to
    ease that process?

The basic idea for a module for addons is to create a directory with the
source file(s), the html file for the manual page and a Makefile.

Please follow the general submitting rules as explained at
https://trac.osgeo.org/grass/wiki/Submitting.

To get an idea of the structure of a suite of modules in Addons, you
could look at the recently added r.sentinel tools:
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.sentinel

Moritz

4

On 12/02/18 18:01, Bernardo Santos wrote:

Dear Moritz,

thanks for the answer and the examples.
I'll try to put the functions and files in this format and test them like that.
I am not sure how to build these makefile files but I'll try to follow the patterns I find in the other examples of modules.
Once this is done, I'll post it here.

Which GRASS version I should use to do that?

You should probably do it with trunk, but 7.4 is also ok as the two are not far from each other.

Regarding the comparison with the other GRASS tools, LSMetrics is complementary to many of the functions the r.li suite offers. I still could not test r.pi since I had some trouble installing it, but I'll try it again so that I can compare both packages. I believe they are also somehow complementary in many of the functions.

Yes, r.pi installation is still an issue. Currently it does not seem configured in a way to be usable by g.extension.

Assuming you are on a *nix like system, the easiest is to download the entire r.pi directory from SVN (https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.pi?rev=72241&format=zip), unzip it somewhere on your system, cd to the r.pi directory and then compile it with

make MODULE_TOPDIR=~/SRC/GRASS/grass_trunk/

where you replace ~/SRC/GRASS/grass_trunk

with the path to your GRASS source code (again 7.4 is ok, and 7.2 probably also).

Moritz

5

On Thu, Feb 15, 2018 at 5:43 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 12/02/18 18:01, Bernardo Santos wrote:

...

Regarding the comparison with the other GRASS tools, LSMetrics is
complementary to many of the functions the r.li suite offers. I still could
not test r.pi since I had some trouble installing it, but I'll try it again
so that I can compare both packages. I believe they are also somehow
complementary in many of the functions.

Yes, r.pi installation is still an issue.

I have probably fixed it in r72243. Please try.

But: I get this compilation error (probably easy to fix but I have no
time right now):

[mneteler@oboe r.pi.library ]$ make MODULE_TOPDIR=~/software/grass74
gcc -shared -o /home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,--no-undefined -Wl,-z,now -Wl,--export-dynamic
-Wl,-rpath-link,/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,-soname,libgrass_rpi.7.4.1svn.so OBJ.x86_64-pc-linux-gnu/draw.o
OBJ.x86_64-pc-linux-gnu/frag.o OBJ.x86_64-pc-linux-gnu/helpers.o
OBJ.x86_64-pc-linux-gnu/stat_method.o -lgrass_gis.7.4.1svn -lm -lm
OBJ.x86_64-pc-linux-gnu/draw.o: In function `draw_line':
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:38:
undefined reference to `swap'
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:39:
undefined reference to `swap'
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:43:
undefined reference to `swap'
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:44:
undefined reference to `swap'
collect2: error: ld returned 1 exit status
make: *** [/home/mneteler/software/grass74/include/Make/Shlib.make:10:
/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so]
Error 1

Then g.extension will probably work with r.pi.

Markus

6

On Thu, Feb 15, 2018 at 5:57 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Thu, Feb 15, 2018 at 5:43 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 12/02/18 18:01, Bernardo Santos wrote:
…

Regarding the comparison with the other GRASS tools, LSMetrics is
complementary to many of the functions the r.li suite offers. I still could
not test r.pi since I had some trouble installing it, but I’ll try it again
so that I can compare both packages. I believe they are also somehow
complementary in many of the functions.

Yes, r.pi installation is still an issue.

I have probably fixed it in r72243. Please try.

But: I get this compilation error (probably easy to fix but I have no
time right now):

[mneteler@oboe r.pi.library ]$ make MODULE_TOPDIR=~/software/grass74
gcc -shared -o /home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,–no-undefined -Wl,-z,now -Wl,–export-dynamic
-Wl,-rpath-link,/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,-soname,libgrass_rpi.7.4.1svn.so OBJ.x86_64-pc-linux-gnu/draw.o
OBJ.x86_64-pc-linux-gnu/frag.o OBJ.x86_64-pc-linux-gnu/helpers.o
OBJ.x86_64-pc-linux-gnu/stat_method.o -lgrass_gis.7.4.1svn -lm -lm
OBJ.x86_64-pc-linux-gnu/draw.o: In function draw_line': /home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:38: undefined reference to swap’
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:39:
undefined reference to swap' /home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:43: undefined reference to swap’
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:44:
undefined reference to `swap’
collect2: error: ld returned 1 exit status
make: *** [/home/mneteler/software/grass74/include/Make/Shlib.make:10:
/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so]
Error 1

swap is in draw.c L3-9

I can not reproduce this error. Do you have any changes in your local copy? Maybe also try make clean, then make again, because

[mneteler@oboe r.pi.library ]$ make MODULE_TOPDIR=~/software/grass74

should produce a lot more output.

Markus M

Then g.extension will probably work with r.pi.

Markus

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

7

On Thu, Feb 15, 2018 at 7:49 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Thu, Feb 15, 2018 at 5:57 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Thu, Feb 15, 2018 at 5:43 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
> On 12/02/18 18:01, Bernardo Santos wrote:
...
>> Regarding the comparison with the other GRASS tools, LSMetrics is
>> complementary to many of the functions the r.li suite offers. I still
>> could
>> not test r.pi since I had some trouble installing it, but I'll try it
>> again
>> so that I can compare both packages. I believe they are also somehow
>> complementary in many of the functions.
>
>
> Yes, r.pi installation is still an issue.

I have probably fixed it in r72243. Please try.

But: I get this compilation error (probably easy to fix but I have no
time right now):

[mneteler@oboe r.pi.library ]$ make MODULE_TOPDIR=~/software/grass74
gcc -shared -o
/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,--no-undefined -Wl,-z,now -Wl,--export-dynamic

-Wl,-rpath-link,/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,-soname,libgrass_rpi.7.4.1svn.so OBJ.x86_64-pc-linux-gnu/draw.o
OBJ.x86_64-pc-linux-gnu/frag.o OBJ.x86_64-pc-linux-gnu/helpers.o
OBJ.x86_64-pc-linux-gnu/stat_method.o -lgrass_gis.7.4.1svn -lm -lm
OBJ.x86_64-pc-linux-gnu/draw.o: In function `draw_line':

/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:38:
undefined reference to `swap'

/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:39:
undefined reference to `swap'

/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:43:
undefined reference to `swap'

/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:44:
undefined reference to `swap'
collect2: error: ld returned 1 exit status
make: *** [/home/mneteler/software/grass74/include/Make/Shlib.make:10:

/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so]
Error 1

swap is in draw.c L3-9

Yes, I saw that - quite confusing that it does not compile (Fedora 27):

I can not reproduce this error. Do you have any changes in your local copy?

all clean and shiny

Maybe also try make clean, then make again, because

yes done. So I get:

[mneteler@oboe r.pi ]$ make MODULE_TOPDIR=~/software/grass74
make -C r.pi.library || echo
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library

/home/mneteler/software/grass74/error.log

make[1]: Entering directory
'/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library'
test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
gcc -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64 -fPIC -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE=\""grasslibs"\"
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DRELDIR=\"/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library\"
-o OBJ.x86_64-pc-linux-gnu/draw.o -c draw.c
draw.c: In function ‘draw_point’:
draw.c:11:62: warning: unused parameter ‘sy’ [-Wunused-parameter]
void draw_point(int *map, int val, int x, int y, int sx, int sy, int width)
                                                              ^~
gcc -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64 -fPIC -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE=\""grasslibs"\"
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DRELDIR=\"/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library\"
-o OBJ.x86_64-pc-linux-gnu/frag.o -c frag.c
gcc -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64 -fPIC -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE=\""grasslibs"\"
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DRELDIR=\"/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library\"
-o OBJ.x86_64-pc-linux-gnu/helpers.o -c helpers.c
gcc -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64 -fPIC -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE=\""grasslibs"\"
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DRELDIR=\"/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library\"
-o OBJ.x86_64-pc-linux-gnu/stat_method.o -c stat_method.c
gcc -shared -o /home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,--no-undefined -Wl,-z,now -Wl,--export-dynamic
-Wl,-rpath-link,/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,-soname,libgrass_rpi.7.4.1svn.so OBJ.x86_64-pc-linux-gnu/draw.o
OBJ.x86_64-pc-linux-gnu/frag.o OBJ.x86_64-pc-linux-gnu/helpers.o
OBJ.x86_64-pc-linux-gnu/stat_method.o -lgrass_gis.7.4.1svn -lm -lm
OBJ.x86_64-pc-linux-gnu/draw.o: In function `draw_line':
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:38:
undefined reference to `swap'
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:39:
undefined reference to `swap'
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:43:
undefined reference to `swap'
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:44:
undefined reference to `swap'
collect2: error: ld returned 1 exit status

Maybe my compiler flags matter?

markusN

8

On Thu, Feb 15, 2018 at 10:38 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Thu, Feb 15, 2018 at 7:49 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Thu, Feb 15, 2018 at 5:57 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Thu, Feb 15, 2018 at 5:43 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 12/02/18 18:01, Bernardo Santos wrote:
…

Regarding the comparison with the other GRASS tools, LSMetrics is
complementary to many of the functions the r.li suite offers. I still
could
not test r.pi since I had some trouble installing it, but I’ll try it
again
so that I can compare both packages. I believe they are also somehow
complementary in many of the functions.

Yes, r.pi installation is still an issue.

I have probably fixed it in r72243. Please try.

But: I get this compilation error (probably easy to fix but I have no
time right now):

[mneteler@oboe r.pi.library ]$ make MODULE_TOPDIR=~/software/grass74
gcc -shared -o
/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,–no-undefined -Wl,-z,now -Wl,–export-dynamic

-Wl,-rpath-link,/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,-soname,libgrass_rpi.7.4.1svn.so OBJ.x86_64-pc-linux-gnu/draw.o
OBJ.x86_64-pc-linux-gnu/frag.o OBJ.x86_64-pc-linux-gnu/helpers.o
OBJ.x86_64-pc-linux-gnu/stat_method.o -lgrass_gis.7.4.1svn -lm -lm
OBJ.x86_64-pc-linux-gnu/draw.o: In function `draw_line’:

/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:38:
undefined reference to `swap’

/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:39:
undefined reference to `swap’

/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:43:
undefined reference to `swap’

/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:44:
undefined reference to `swap’
collect2: error: ld returned 1 exit status
make: *** [/home/mneteler/software/grass74/include/Make/Shlib.make:10:

/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so]
Error 1

swap is in draw.c L3-9

Yes, I saw that - quite confusing that it does not compile (Fedora 27):

I can not reproduce this error. Do you have any changes in your local copy?

all clean and shiny

Maybe also try make clean, then make again, because

yes done. So I get:

[mneteler@oboe r.pi ]$ make MODULE_TOPDIR=~/software/grass74
make -C r.pi.library || echo
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library

/home/mneteler/software/grass74/error.log
make[1]: Entering directory
‘/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library’
test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
gcc -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64 -fPIC -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE="“grasslibs”"
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DRELDIR="/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library"
-o OBJ.x86_64-pc-linux-gnu/draw.o -c draw.c
draw.c: In function ‘draw_point’:
draw.c:11:62: warning: unused parameter ‘sy’ [-Wunused-parameter]
void draw_point(int *map, int val, int x, int y, int sx, int sy, int width)
^~
gcc -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64 -fPIC -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE="“grasslibs”"
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DRELDIR="/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library"
-o OBJ.x86_64-pc-linux-gnu/frag.o -c frag.c
gcc -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64 -fPIC -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE="“grasslibs”"
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DRELDIR="/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library"
-o OBJ.x86_64-pc-linux-gnu/helpers.o -c helpers.c
gcc -g -Wall -Wshadow -Wlogical-op
-Werror-implicit-function-declaration -fPIC -fno-common -fexceptions
-Wextra -Wunused -Waggressive-loop-optimizations -Wreturn-type
-Wfatal-errors -march=native -std=gnu99 -fexceptions -fstack-protector
-m64 -fPIC -I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DPACKAGE="“grasslibs”"
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-I/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/include
-DRELDIR="/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library"
-o OBJ.x86_64-pc-linux-gnu/stat_method.o -c stat_method.c
gcc -shared -o /home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib/libgrass_rpi.7.4.1svn.so
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-L/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,–no-undefined -Wl,-z,now -Wl,–export-dynamic
-Wl,-rpath-link,/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/lib
-Wl,-soname,libgrass_rpi.7.4.1svn.so OBJ.x86_64-pc-linux-gnu/draw.o
OBJ.x86_64-pc-linux-gnu/frag.o OBJ.x86_64-pc-linux-gnu/helpers.o
OBJ.x86_64-pc-linux-gnu/stat_method.o -lgrass_gis.7.4.1svn -lm -lm
OBJ.x86_64-pc-linux-gnu/draw.o: In function draw_line': /home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:38: undefined reference to swap’
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:39:
undefined reference to swap' /home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:43: undefined reference to swap’
/home/mneteler/software/grass-addons/grass7/raster/r.pi/r.pi.library/draw.c:44:
undefined reference to `swap’
collect2: error: ld returned 1 exit status

Maybe my compiler flags matter?

I can’t reproduce with your compiler flags. A wild guess: in draw.c:L3 try to replace inline with static

Markus M

markusN

9

On Fri, Feb 16, 2018 at 9:42 AM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
...

I can't reproduce with your compiler flags. A wild guess: in draw.c:L3 try
to replace inline with static

Yes, this helps. I didn't submit the change, will you do that?

markusN

10

On Fri, Feb 16, 2018 at 10:05 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Fri, Feb 16, 2018 at 9:42 AM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
…

I can’t reproduce with your compiler flags. A wild guess: in draw.c:L3 try
to replace inline with static

Yes, this helps. I didn’t submit the change, will you do that?

done in r72247

Markus M

markusN