Some modules fail to compile

[ewcgrass]

Grass 7.2 svn 30 July 2016 compiles without errors, but v.buffer fails to be created (greyed out in GUI menu, confirmed missing by searching distro folder created when compiling and also /usr/local/grass-7.2.svn folder). Also greyed out in GUI menu are r.in.lidar, v.in.lidar and v.out.postgis, which also appear to be nowhere in installation or complied distro folders.

Re. v.buffer, geos-3.4.2-3 is installed at normal location.

Compilation error.log is attached.

[wenzeslaus]

These all are modules with non-trivial dependencies (v.buffer - GEOS, r.in.lidar and v.in.lidar - libLAS, v.out.postgis - libpq). Please, check the configure command and the configure log (this will hopefully tell more).

Everything seems to work after compilation (just make, no install) for me on Ubuntu with trunk and 72 branch.

./configure \
  --with-geos \
  --with-liblas \
  --with-postgres=yes --with-postgres-includes="/usr/include/postgresql" \
  ...

  GEOS support:               yes
  ...
  libLAS support:             yes
  ...
  PostgreSQL support:         yes

$ ls dist.x86_64-pc-linux-gnu/*/{v.out.postgis,v.in.lidar,v.in.lidar,v.buffer}
dist.x86_64-pc-linux-gnu/bin/v.buffer    dist.x86_64-pc-linux-gnu/bin/v.in.lidar
dist.x86_64-pc-linux-gnu/bin/v.in.lidar  dist.x86_64-pc-linux-gnu/bin/v.out.postgis

[ewcgrass]

Thanks for your prompt reply.

FYI, this is on Fedora 21 (yes, no longer supported, but with latest updates installed).

I compiled originally with default settings, and geos, liblas and postgres support are excluded by default (perhaps a change is required to include them by default?).

By including support for geos and liblas (I didn't include support for postgres in case it removed default support for SQlite?, which I wish to maintain), and installing laszip-devel and libgeotiff-devel and making links to original files to create libboost_program_options.so and libboost_thread.so to remedy failed configurations, all finally configured fine. A file with copy of the command used and output obtained, and config.log, are attached.

However, now compilation fails at v.buffer. Running "make" inside /vector/v.buffer directory yields this:

--snip-- [rick@localhost v.buffer]$ make

test -d OBJ.x86_64-pc-linux-gnu

mkdir -p OBJ.x86_64-pc-linux-gnu

gcc -g -Wall -I/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/include -I/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/include -I/usr/include/gdal -I/usr/include -I/usr/include -DPACKAGE=\""grassmods"\" -I/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/include -I/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"vector/v.buffer\" -o OBJ.x86_64-pc-linux-gnu/main.o -c main.c gcc -g -Wall -I/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/include -I/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/include -I/usr/include/gdal -I/usr/include -I/usr/include -DPACKAGE=\""grassmods"\" -I/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/include -I/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"vector/v.buffer\" -o OBJ.x86_64-pc-linux-gnu/geos.o -c geos.c : && gcc -L/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/lib -L/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/lib -Wl,--export-dynamic -Wl,-rpath-link,/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/lib -o /home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/bin/v.buffer OBJ.x86_64-pc-linux-gnu/main.o OBJ.x86_64-pc-linux-gnu/geos.o -lgrass_vector.7.2.svn -lgrass_dbmiclient.7.2.svn -lgrass_dbmibase.7.2.svn -lgrass_gis.7.2.svn -lm -L/usr/lib64 -lgeos -lgeos_c -lm OBJ.x86_64-pc-linux-gnu/geos.o: In function `geos_buffer': /home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/vector/v.buffer/geos.c:153: undefined reference to `Vect_read_area_geos' /home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/vector/v.buffer/geos.c:155: undefined reference to `Vect_read_line_geos' collect2: error: ld returned 1 exit status ../../include/Make/Module.make:18: recipe for target '/home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/bin/v.buffer' failed make: * home/rick/temp/newapps/apps/science/gis-mapping/grass/grass72/grass-7.2.svn_src_snapshot_2016_07_30/dist.x86_64-pc-linux-gnu/bin/v.buffer Error 1 [rick@localhost v.buffer]$ --snip--

In case this might be of any help, I installed the 03-Aug-2016 svn generic binary of grass7.2 and v.buffer in that installation runs fine (geos-4.3.2 is installed on system). However, borrowing v.buffer binary from it and placing it into the original /usr/local/grass72/bin directory and running that, v.buffer output complains about undefined symbol for Vect_read_line_geos and Vect_read_line_geos.

[wenzeslaus]

Replying to ewcgrass:

I compiled originally with default settings, and geos, liblas and postgres support are excluded by default (perhaps a change is required to include them by default?).

Possibly. You can open a ticket for it.

(I didn't include support for postgres in case it removed default support for SQlite?, which I wish to maintain)

You can do it. They are independent.

--snip--

You can use {{{ and }}} to make a snipped, see WikiFormatting at the top right corner of the form.

OBJ.x86_64-pc-linux-gnu/geos.o: In function `geos_buffer':
vector/v.buffer/geos.c:153: undefined reference to `Vect_read_area_geos'

This looks like a GRASS GIS function to communicate with GEOS was disabled because of missing GEOS. You probably need to recompile the library. Do make distclean in the source code top directory:

make distclean && svn up && ./configure ... && make

v.buffer output complains about undefined symbol for Vect_read_line_geos and Vect_read_line_geos.

This seems to fit with the above, i.e. a missing symbol in the library.

[ewcgrass]

Success. Thank you.

I'm guessing failure had to do with doing make clean instead of make distclean following first attempts.

I will open a ticket regarding default settings for geos, libLAS and libpq and missing requirements for laszip and libgeotiff.

[wenzeslaus]

Good. Closing this one as invalid as nothing was wrong in the code.

[glynn]

Replying to ewcgrass:

I'm guessing failure had to do with doing make clean instead of make distclean following first attempts.

Not directly, no. "make distclean" performs "make clean" and also removes the files which are generated by configure. In terms of building, the only difference is that "make clean && make" will re-build everything with the existing configuration while "make distclean && make" will generate an error.

If changes to installed libraries render the configuration invalid, you need to re-run configure. There's no difference between "make clean && configure && make" and "make distclean && configure && make"; both will rebuild everything with a new configuration.

"make distclean" exists primarily to minimise differences between a working directory and a clean checkout. If it forces you to re-run configure (rather than silently using a stale configuration), that's a side-effect.