[GRASS-dev] GRASS 7.4.0 won't compile

GRASS GRASS developer
,
1

Michael,

I take liberty to cc the list:

On Mon, Jan 29, 2018 at 9:37 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Hi Markus,

I just tried compiling GRASS 7.4.0 and it failed with a bunch of errors.
This is what I had before when I tried to compile the release branch. 7.4svn
compiles but not the stable release.

It is a gdal problem. But I DO have gdal 2.0.0 and liberal 2.0.0 installed
in my build environment.

I think I have an idea:

imac:test cmbarton$ cd
/Users/cmbarton/grass_source/grass-7.4.0/display/d.erase
imac:d.erase cmbarton$ make -j4
if [
"/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin/d.erase"
!= "" ] ; then
GISRC=/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/demolocation/.grassrc74
GISBASE=/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0
PATH="/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/scripts:$PATH"
LD_RUN_PATH="/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/scripts:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib:/lib"
PYTHONPATH="/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/etc/python:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/gui/wxpython:$PYTHONPATH"
LC_ALL=C LANG=C LANGUAGE=C
/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin/d.erase
--html-description < /dev/null | grep -v '</body>\|</html>' >
d.erase.tmp.html ; fi
dyld: Library not loaded: libgdal.20.dylib

The libgdal name is referenced here:

grep libgdal lib/raster/*
lib/raster/gdal.c: "libgdal.so.20",
lib/raster/gdal.c: "libgdal.so.1",
lib/raster/gdal.c: "libgdal.1.1.so",
lib/raster/gdal.c: "libgdal.so",
lib/raster/gdal.c: "libgdal1.6.0.so",
lib/raster/gdal.c: "libgdal1.7.0.so",
lib/raster/gdal.c: "libgdal-1.dll",

Probably also libgdal.20.dylib needs to go there?

  Referenced from:
/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib/libgrass_gproj.7.4.0.dylib
  Reason: image not found
make: *** [d.erase.tmp.html] Error 1

Maybe you can try?

Markus

2

Thanks Markus,

The odd thing is that 7.2.2 and the dev version of 7.4 (from the 7.4 svn repository checkout) compile with no errors. But the release branch of 7.4 does not.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jan 29, 2018, at 2:07 PM, Markus Neteler <neteler@osgeo.org> wrote:

Michael,

I take liberty to cc the list:

On Mon, Jan 29, 2018 at 9:37 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Hi Markus,

I just tried compiling GRASS 7.4.0 and it failed with a bunch of errors.
This is what I had before when I tried to compile the release branch. 7.4svn
compiles but not the stable release.

It is a gdal problem. But I DO have gdal 2.0.0 and liberal 2.0.0 installed
in my build environment.

I think I have an idea:

imac:test cmbarton$ cd
/Users/cmbarton/grass_source/grass-7.4.0/display/d.erase
imac:d.erase cmbarton$ make -j4
if [
“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin/d.erase”
!= “” ] ; then
GISRC=/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/demolocation/.grassrc74
GISBASE=/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0
PATH=“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/scripts:$PATH”
LD_RUN_PATH=“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/scripts:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib:/lib”
PYTHONPATH=“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/etc/python:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/gui/wxpython:$PYTHONPATH”
LC_ALL=C LANG=C LANGUAGE=C
/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin/d.erase
–html-description < /dev/null | grep -v ‘|’ >
d.erase.tmp.html ; fi
dyld: Library not loaded: libgdal.20.dylib

The libgdal name is referenced here:

grep libgdal lib/raster/*
lib/raster/gdal.c: “libgdal.so.20”,
lib/raster/gdal.c: “libgdal.so.1”,
lib/raster/gdal.c: “libgdal.1.1.so”,
lib/raster/gdal.c: “libgdal.so”,
lib/raster/gdal.c: “libgdal1.6.0.so”,
lib/raster/gdal.c: “libgdal1.7.0.so”,
lib/raster/gdal.c: “libgdal-1.dll”,

Probably also libgdal.20.dylib needs to go there?

Referenced from:
/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib/libgrass_gproj.7.4.0.dylib
Reason: image not found
make: *** [d.erase.tmp.html] Error 1

Maybe you can try?

Markus

3

Did you do anything differently?

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

…Sent from my iPad

···

On Jan 29, 2018, at 4:19 PM, Eric Hutton <hutton.eric@gmail.com> wrote:

Hi Michael

I just successfully (I think) built the 7.4.0 stable release that I got from the link Markus sent. I haven’t really dug into it, but it, at least, compiled and installed without error.

Sorry about the patches. The patches I use have a relative path, it’s just that it’s relative to the build folder (and so includes the grass folder with the version name). I like to do this so that it’s explicit what version of grass the patch goes with. Assuming the patches don’t change with new versions of grass, I usually just run something like the following,

$ sed -e ‘s/7.2.2/7.4.0/g’ -i ‘’ *patch

I’ll see if I can build an app with this version. I’ll let you know how it goes.

Eric

On Mon, Jan 29, 2018 at 3:11 PM Michael Barton <Michael.Barton@asu.edu> wrote:

Thanks Markus,

The odd thing is that 7.2.2 and the dev version of 7.4 (from the 7.4 svn repository checkout) compile with no errors. But the release branch of 7.4 does not.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jan 29, 2018, at 2:07 PM, Markus Neteler <neteler@osgeo.org> wrote:

Michael,

I take liberty to cc the list:

On Mon, Jan 29, 2018 at 9:37 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Hi Markus,

I just tried compiling GRASS 7.4.0 and it failed with a bunch of errors.
This is what I had before when I tried to compile the release branch. 7.4svn
compiles but not the stable release.

It is a gdal problem. But I DO have gdal 2.0.0 and liberal 2.0.0 installed
in my build environment.

I think I have an idea:

imac:test cmbarton$ cd
/Users/cmbarton/grass_source/grass-7.4.0/display/d.erase
imac:d.erase cmbarton$ make -j4
if [
“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin/d.erase”
!= “” ] ; then
GISRC=/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/demolocation/.grassrc74
GISBASE=/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0
PATH=“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/scripts:$PATH”
LD_RUN_PATH=“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/scripts:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib:/lib”
PYTHONPATH=“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/etc/python:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/gui/wxpython:$PYTHONPATH”
LC_ALL=C LANG=C LANGUAGE=C
/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin/d.erase
–html-description < /dev/null | grep -v ‘|’ >
d.erase.tmp.html ; fi
dyld: Library not loaded: libgdal.20.dylib

The libgdal name is referenced here:

grep libgdal lib/raster/*
lib/raster/gdal.c: “libgdal.so.20”,
lib/raster/gdal.c: “libgdal.so.1”,
lib/raster/gdal.c: “libgdal.1.1.so”,
lib/raster/gdal.c: “libgdal.so”,
lib/raster/gdal.c: “libgdal1.6.0.so”,
lib/raster/gdal.c: “libgdal1.7.0.so”,
lib/raster/gdal.c: “libgdal-1.dll”,

Probably also libgdal.20.dylib needs to go there?

Referenced from:
/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib/libgrass_gproj.7.4.0.dylib
Reason: image not found
make: *** [d.erase.tmp.html] Error 1

Maybe you can try?

Markus

4

Hi Eric,

There seem to be changes in many of the patches (not just to point to grass-74). Should these changes be applied to the 7.2 recipe as well? I can reinstall an unmatched 7.4.0, repatch and try again on Wednesday.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jan 29, 2018, at 4:52 PM, Eric Hutton <hutton.eric@gmail.com> wrote:

I didn’t. I just updated the patches to point to 7.4.0 and the meta.yaml file to point to the url Markus sent. I then ran,

$ conda build ./recipe -c noaa-orr-erd -c conda-forge

I’ve uploaded the latest changes to GitHub on the v7.4 branch,

https://github.com/mcflugen/grass-conda-build/tree/v7.4

As I said, though, I didn’t really have a close look at things yet so it’s possible I may have made a mistake.

Eric

On Mon, Jan 29, 2018 at 4:47 PM Michael Barton <Michael.Barton@asu.edu> wrote:

Did you do anything differently?

Michael Barton
School of Human Evolution &Social Change

Center for Social Dynamics & Complexity

Arizona State University

…Sent from my iPad

On Jan 29, 2018, at 4:19 PM, Eric Hutton <hutton.eric@gmail.com> wrote:

Hi Michael

I just successfully (I think) built the 7.4.0 stable release that I got from the link Markus sent. I haven’t really dug into it, but it, at least, compiled and installed without error.

Sorry about the patches. The patches I use have a relative path, it’s just that it’s relative to the build folder (and so includes the grass folder with the version name). I like to do this so that it’s explicit what version of grass the patch goes with. Assuming the patches don’t change with new versions of grass, I usually just run something like the following,

$ sed -e ‘s/7.2.2/7.4.0/g’ -i ‘’ *patch

I’ll see if I can build an app with this version. I’ll let you know how it goes.

Eric

On Mon, Jan 29, 2018 at 3:11 PM Michael Barton <Michael.Barton@asu.edu> wrote:

Thanks Markus,

The odd thing is that 7.2.2 and the dev version of 7.4 (from the 7.4 svn repository checkout) compile with no errors. But the release branch of 7.4 does not.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jan 29, 2018, at 2:07 PM, Markus Neteler <neteler@osgeo.org> wrote:

Michael,

I take liberty to cc the list:

On Mon, Jan 29, 2018 at 9:37 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Hi Markus,

I just tried compiling GRASS 7.4.0 and it failed with a bunch of errors.
This is what I had before when I tried to compile the release branch. 7.4svn
compiles but not the stable release.

It is a gdal problem. But I DO have gdal 2.0.0 and liberal 2.0.0 installed
in my build environment.

I think I have an idea:

imac:test cmbarton$ cd
/Users/cmbarton/grass_source/grass-7.4.0/display/d.erase
imac:d.erase cmbarton$ make -j4
if [
“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin/d.erase”
!= “” ] ; then
GISRC=/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/demolocation/.grassrc74
GISBASE=/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0
PATH=“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/scripts:$PATH”
LD_RUN_PATH=“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/scripts:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib:/lib”
PYTHONPATH=“/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/etc/python:/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/gui/wxpython:$PYTHONPATH”
LC_ALL=C LANG=C LANGUAGE=C
/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/bin/d.erase
–html-description < /dev/null | grep -v ‘|’ >
d.erase.tmp.html ; fi
dyld: Library not loaded: libgdal.20.dylib

The libgdal name is referenced here:

grep libgdal lib/raster/*
lib/raster/gdal.c: “libgdal.so.20”,
lib/raster/gdal.c: “libgdal.so.1”,
lib/raster/gdal.c: “libgdal.1.1.so”,
lib/raster/gdal.c: “libgdal.so”,
lib/raster/gdal.c: “libgdal1.6.0.so”,
lib/raster/gdal.c: “libgdal1.7.0.so”,
lib/raster/gdal.c: “libgdal-1.dll”,

Probably also libgdal.20.dylib needs to go there?

Referenced from:
/Users/cmbarton/grass_source/grass-7.4.0/dist.x86_64-apple-darwin17.4.0/lib/libgrass_gproj.7.4.0.dylib
Reason: image not found
make: *** [d.erase.tmp.html] Error 1

Maybe you can try?

Markus

5

Michael, Eric,

On Tue, Jan 30, 2018 at 1:28 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

Hi Eric,

There seem to be changes in many of the patches (not just to point to
grass-74). Should these changes be applied to the 7.2 recipe as well? I can
reinstall an unmatched 7.4.0, repatch and try again on Wednesday.

I found the patches at
https://github.com/mcflugen/grass-conda-build/tree/v7.4/recipe

I wonder why not apply [some of] them to upstream, i.e. the GRASS GIS
source code?
Like

https://github.com/mcflugen/grass-conda-build/blob/v7.4/recipe/aclocal.m4.patch
https://github.com/mcflugen/grass-conda-build/blob/v7.4/recipe/configure.patch
etc.
?

Markus

6

Hi Eric,

On Tue, Jan 30, 2018 at 8:02 PM, Eric Hutton <hutton.eric@gmail.com> wrote:

Hi Markus

We should definitely do this at some point. The current patches were done
just for Mac and just for building with conda. I haven't tested them all
that much on linux or building without conda. I'm fairly certain that, at
this point, they may break things.

Yes, for sure we need careful testing prior to update in SVN.

If I wanted to incorporate some of these, what is the process? Iis there
someplace I would make a pull request (or similar)?

Yes, here:
https://trac.osgeo.org/grass/

If you don't have a login (OSGeo--ID), you can create one here:
https://www.osgeo.org/community/getting-started-osgeo/osgeo_userid/

Markus

7

Yes. We are still testing this now. But at some point we should be able to send this back to the SVN. I could do when we get to that point.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Jan 30, 2018, at 12:29 PM, Markus Neteler <neteler@osgeo.org> wrote:

Hi Eric,

On Tue, Jan 30, 2018 at 8:02 PM, Eric Hutton <hutton.eric@gmail.com> wrote:

Hi Markus

We should definitely do this at some point. The current patches were done
just for Mac and just for building with conda. I haven’t tested them all
that much on linux or building without conda. I’m fairly certain that, at
this point, they may break things.

Yes, for sure we need careful testing prior to update in SVN.

If I wanted to incorporate some of these, what is the process? Iis there
someplace I would make a pull request (or similar)?

Yes, here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_&d=DwIBaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=4g1yV8rcv_iLlGauLKHPAJX1E9_pxh8SGpRroF-TlXs&s=6MLl3YIfiefguGEuxrqYxZ1OIiqCQZrOGwYe5IquN_A&e=

If you don’t have a login (OSGeo–ID), you can create one here:
OSGeo Services UserID - OSGeo

Markus