[GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

I tried again to install 7.1 head without GUI using homwbrew, and I get
the following error:

,----
| bash-4.3$ less /Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd /private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [ "/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts/d.rast.leg" != "" ] ; then GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/demolocation/.grassrc71 GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0 PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:$PATH" PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH" DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:" LC_ALL=C /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts/d.rast.leg --html-description < /dev/null | grep -v '</body>\|</html>' > d.rast.leg.tmp.html ; fi
| dyld: Library not loaded: /usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib
| Referenced from: /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a dynamic
library
(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is incompatible
with Macports) So, I figured that I would just tried to install grass7
using macports. It does seem to install, but the gui doesn’t work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to the GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-- Adam

On 3/15/16, 9:50 AM, "Rainer M Krug" <Rainer@krugs.de> wrote:

Michael Barton <Michael.Barton@asu.edu> writes:

The reason is that I (and William) package some key dependencies with
the binary. The most important is wxPython, which is required by the
GUI. If a user does not have exactly the same version of wxPython used
to compile the binary, the GUI will fail. Making this more complicated
is the fact that the only versions of wxPython that work completely
correctly with Mac GRASS are 32 bit. But some other components are 64
bit. This means that I need to compile GRASS with 32/64 bit dual
architecture. So this is a consequence of making binaries that run on
anyone's Mac (except the newest system with SIP enabled).

OK - so if I understand you correctly, installing via homebrew, should
not be that difficult, as GRASS is compiled for a specific wxPython -
correct?

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 Mar 15, 2016, at 3:14 PM, Carlos Grohmann
    <carlos.grohmann@gmail.com> wrote:

    I run GRASS on OSX El Capitan (with SIP disabled). I don't think
    that setting up a CLI-only version would be a solution as well. As
    Rainer said, other software runs natively (see QGIS) and they
    don't have any problems with OSX/SIP. We should look into that.
    
    I don't understand why GRASS is offending SIP. Perhaps we should
    seek out for help from others. Maybe Apple itself.
    
    One point is that we need to disable SIP for the binary provided
    by Michael Barton, but not if you compile it from source (or using
    homebrew), so this could be fixable by changing paths, like Adam
    suggested. Homebrew uses /usr/local, why can't we?
    
    best
    
    Carlos
    
    On Tue, Mar 15, 2016 at 9:51 AM, Adam Dershowitz
    <adershowitz@exponent.com> wrote:
    
    Yes, SIP is a new security feature that prevents any applications
        from
        writing to a few key OS paths. I believe that it really is
        that simple.
        (see: https://support.apple.com/en-us/HT204899 )
        Which, does beg the questionŠwhy does running GRASS require
        writes to any
        of these folders? That suggests that GRASS is doing something
        that it
        shouldn¹t be doing. Why should it be writing to system folders
        at all at
        runtime?
        It is the only application that I have run into that has any
        problems with
        SIP. It would seem that this should be an easy fix. (for
        example just
        use /usr/local instead of /usr, or whatever the problem folder
        is).
        
        -- Adam
        
    --
    
    Prof. Carlos Henrique Grohmann
    Institute of Energy and Environment - Univ. of São Paulo, Brazil
    - Digital Terrain Analysis | GIS | Remote Sensing -
    
    http://carlosgrohmann.com
    http://orcid.org/0000-0001-5073-5572
    
    ________________
    Can’t stop the signal.

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

This is also a known issue, related to but separate from the packaging issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find the in-compilation copies of the libraries so it can run the modules to create the help files.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging so that everything within the GRASS app package looks directly inside the package for libraries and not rely on DYLD_LIBRARY_PATH. Homebrew, Macports and /usr/local builds don't need to worry about it because the extra dependencies that are bundled in the app are already in their proper place.

The compilation issue needs work to compile all libraries with the temporary path inside the libraries and modules (this part is easy) so that during compilation help file generation works. And then during installation change all the embedded library paths to the final destination (this is harder, to figure out the complex makefile include system of GRASS to get this operation in the right place). Homebrew, Macports, /usr/local AND app installs do have a problem with this. It works for Michael (and me) for the "official" packages because we compile on older systems that don't have SIP.

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I get
the following error:

,----
| bash-4.3$ less /Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd /private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [ "/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts/d.rast.leg" != "" ] ; then GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/demolocation/.grassrc71 GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0 PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:$PATH" PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH" DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:" LC_ALL=C /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts/d.rast.leg --html-description < /dev/null | grep -v '</body>\|</html>' > d.rast.leg.tmp.html ; fi
| dyld: Library not loaded: /usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib
| Referenced from: /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a dynamic
library
(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is incompatible
with Macports) So, I figured that I would just tried to install grass7
using macports. It does seem to install, but the gui doesn’t work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to the GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-- Adam

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy

I don’t see an option to do that. The portfile has a few variants, but
nothing related to the gui.

-- Adam

On 3/15/16, 12:32 PM, "Rainer M Krug" <Rainer@krugs.de> wrote:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is
incompatible
with Macports) So, I figured that I would just tried to install grass7
using macports. It does seem to install, but the gui doesn’t work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to the
GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-- Adam

On 3/15/16, 9:50 AM, "Rainer M Krug" <Rainer@krugs.de> wrote:

Michael Barton <Michael.Barton@asu.edu> writes:

The reason is that I (and William) package some key dependencies with
the binary. The most important is wxPython, which is required by the
GUI. If a user does not have exactly the same version of wxPython used
to compile the binary, the GUI will fail. Making this more complicated
is the fact that the only versions of wxPython that work completely
correctly with Mac GRASS are 32 bit. But some other components are 64
bit. This means that I need to compile GRASS with 32/64 bit dual
architecture. So this is a consequence of making binaries that run on
anyone's Mac (except the newest system with SIP enabled).

OK - so if I understand you correctly, installing via homebrew, should
not be that difficult, as GRASS is compiled for a specific wxPython -
correct?

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 Mar 15, 2016, at 3:14 PM, Carlos Grohmann
    <carlos.grohmann@gmail.com> wrote:

    I run GRASS on OSX El Capitan (with SIP disabled). I don't think
    that setting up a CLI-only version would be a solution as well. As
    Rainer said, other software runs natively (see QGIS) and they
    don't have any problems with OSX/SIP. We should look into that.
    
    I don't understand why GRASS is offending SIP. Perhaps we should
    seek out for help from others. Maybe Apple itself.
    
    One point is that we need to disable SIP for the binary provided
    by Michael Barton, but not if you compile it from source (or using
    homebrew), so this could be fixable by changing paths, like Adam
    suggested. Homebrew uses /usr/local, why can't we?
    
    best
    
    Carlos
    
    On Tue, Mar 15, 2016 at 9:51 AM, Adam Dershowitz
    <adershowitz@exponent.com> wrote:
    
    Yes, SIP is a new security feature that prevents any applications
        from
        writing to a few key OS paths. I believe that it really is
        that simple.
        (see: https://support.apple.com/en-us/HT204899 )
        Which, does beg the questionŠwhy does running GRASS require
        writes to any
        of these folders? That suggests that GRASS is doing something
        that it
        shouldn¹t be doing. Why should it be writing to system folders
        at all at
        runtime?
        It is the only application that I have run into that has any
        problems with
        SIP. It would seem that this should be an easy fix. (for
        example just
        use /usr/local instead of /usr, or whatever the problem folder
        is).
        
        -- Adam
        
    --
    
    Prof. Carlos Henrique Grohmann
    Institute of Energy and Environment - Univ. of São Paulo, Brazil
    - Digital Terrain Analysis | GIS | Remote Sensing -
    
    http://carlosgrohmann.com
    http://orcid.org/0000-0001-5073-5572
    
    ________________
    Can’t stop the signal.

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
the in-compilation copies of the libraries so it can run the modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
so that everything within the GRASS app package looks directly inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry about it
because the extra dependencies that are bundled in the app are already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is easy) so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take, i.e. use
the generated binaries to generate the help files during installation?
Wouldn't it be much easier to do this during installation?

And then during installation change all the embedded library paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the right
place).

The paths are in the grass script file? Or in others as well?

Wouldn't it make sense to

1) split the generation of the help files from the build step into a
separate make target
2) call the make target for help pages as a last step in the install
step?

This might make packaging more difficult, but wouldn't it make the whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem with
this.

It worked with Yosemite without problems. So this only needs to be done,
because of the issues you describe above?

It works for Michael (and me) for the "official" packages because we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation and
installation working using homebrew so that there is at least one way of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I get
the following error:

,----
| bash-4.3$ less /Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd /private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
| "/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts/d.rast.leg"
| != "" ] ; then
| GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/demolocation/.grassrc71
| GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0
| PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:$PATH"
| PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
| DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
| /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded: /usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib
| Referenced from:
| /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a dynamic
library
(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is incompatible
with Macports) So, I figured that I would just tried to install grass7
using macports. It does seem to install, but the gui doesn’t work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to the GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-- Adam

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if
you ARE a maniacally depressed robot? No, don't try and answer, I'm
50,000 times more intelligent than you and even I don't know the
answer...

- HitchHiker's Guide to the Galaxy

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

Adam Dershowitz <adershowitz@exponent.com> writes:

I don’t see an option to do that. The portfile has a few variants, but
nothing related to the gui.

OK - but it is interesting, that GRASS does actually compile and install
successfully - see the email from William.

-- Adam

On 3/15/16, 12:32 PM, "Rainer M Krug" <Rainer@krugs.de> wrote:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is
incompatible
with Macports) So, I figured that I would just tried to install grass7
using macports. It does seem to install, but the gui doesn’t work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to the
GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-- Adam

On 3/15/16, 9:50 AM, "Rainer M Krug" <Rainer@krugs.de> wrote:

Michael Barton <Michael.Barton@asu.edu> writes:

The reason is that I (and William) package some key dependencies with
the binary. The most important is wxPython, which is required by the
GUI. If a user does not have exactly the same version of wxPython used
to compile the binary, the GUI will fail. Making this more complicated
is the fact that the only versions of wxPython that work completely
correctly with Mac GRASS are 32 bit. But some other components are 64
bit. This means that I need to compile GRASS with 32/64 bit dual
architecture. So this is a consequence of making binaries that run on
anyone's Mac (except the newest system with SIP enabled).

OK - so if I understand you correctly, installing via homebrew, should
not be that difficult, as GRASS is compiled for a specific wxPython -
correct?

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 Mar 15, 2016, at 3:14 PM, Carlos Grohmann
    <carlos.grohmann@gmail.com> wrote:

    I run GRASS on OSX El Capitan (with SIP disabled). I don't think
    that setting up a CLI-only version would be a solution as well. As
    Rainer said, other software runs natively (see QGIS) and they
    don't have any problems with OSX/SIP. We should look into that.
    
    I don't understand why GRASS is offending SIP. Perhaps we should
    seek out for help from others. Maybe Apple itself.
    
    One point is that we need to disable SIP for the binary provided
    by Michael Barton, but not if you compile it from source (or using
    homebrew), so this could be fixable by changing paths, like Adam
    suggested. Homebrew uses /usr/local, why can't we?
    
    best
    
    Carlos
    
    On Tue, Mar 15, 2016 at 9:51 AM, Adam Dershowitz
    <adershowitz@exponent.com> wrote:
    
    Yes, SIP is a new security feature that prevents any applications
        from
        writing to a few key OS paths. I believe that it really is
        that simple.
        (see: https://support.apple.com/en-us/HT204899 )
        Which, does beg the questionŠwhy does running GRASS require
        writes to any
        of these folders? That suggests that GRASS is doing something
        that it
        shouldn¹t be doing. Why should it be writing to system folders
        at all at
        runtime?
        It is the only application that I have run into that has any
        problems with
        SIP. It would seem that this should be an easy fix. (for
        example just
        use /usr/local instead of /usr, or whatever the problem folder
        is).
        
        -- Adam
        
    --
    
    Prof. Carlos Henrique Grohmann
    Institute of Energy and Environment - Univ. of São Paulo, Brazil
    - Digital Terrain Analysis | GIS | Remote Sensing -
    
    http://carlosgrohmann.com
    http://orcid.org/0000-0001-5073-5572
    
    ________________
    Can’t stop the signal.

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
the in-compilation copies of the libraries so it can run the modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
so that everything within the GRASS app package looks directly inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry about it
because the extra dependencies that are bundled in the app are already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is easy) so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take, i.e. use
the generated binaries to generate the help files during installation?
Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I can remember, it's nothing specific to OS X. Changing this would be major.

And then during installation change all the embedded library paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the right
place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step into a
separate make target
2) call the make target for help pages as a last step in the install
step?

This might make packaging more difficult, but wouldn't it make the whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem with
this.

It worked with Yosemite without problems. So this only needs to be done,
because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

It works for Michael (and me) for the "official" packages because we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation and
installation working using homebrew so that there is at least one way of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I get
the following error:

,----
| bash-4.3$ less /Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd /private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
| "/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts/d.rast.leg"
| != "" ] ; then
| GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/demolocation/.grassrc71
| GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0
| PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:$PATH"
| PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
| DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
| /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded: /usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib
| Referenced from:
| /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a dynamic
library
(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is incompatible
with Macports) So, I figured that I would just tried to install grass7
using macports. It does seem to install, but the gui doesn’t work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to the GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
<grass-user-bounces@lists.osgeo.org on behalf of woklist@kyngchaos.com>
wrote:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
the in-compilation copies of the libraries so it can run the modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's
causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
so that everything within the GRASS app package looks directly inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry about it
because the extra dependencies that are bundled in the app are already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is easy) so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take, i.e. use
the generated binaries to generate the help files during installation?
Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I can
remember, it's nothing specific to OS X. Changing this would be major.

And then during installation change all the embedded library paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the right
place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step into a
separate make target
2) call the make target for help pages as a last step in the install
step?

This might make packaging more difficult, but wouldn't it make the whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem with
this.

It worked with Yosemite without problems. So this only needs to be done,
because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

I wonder if you can explain this anymore. Because, it is not at all clear
to me. DYLD_LIBRARY_PATH is something that is used all the time and works
fine in El Capitan for most Applications. The only thing that SIP
provides, if I understand correctly, is that it is not possible for an
application to write to /System /bin /sbin or /usr (and a few Apple
specifics in /Applications). Writing to /usr/local and /usr/lib should be
OK. Just having all the different versions of libraries around, and
dynamically finding them should work fine.
So, during run time, why does GRASS attempt to write to /usr (or one of
the other Apple owned folders? If it is using DYLD_LIBRARY_PATH to find
the necessary libraries from within the GRASS bundle, there should be no
need to write there.
Is it doing something unusual, such as at startup it tries to copy a few
files from the bundle to /usr so that it doesn¹t have to change
DYLD_LIBRARY_PATH? Even if that is the case, just changing those paths to
/usr/local would solve the SIP problem.

If the problem relates to how GRASS finds the correct version of
libraries, at least as a work around, it should be possible to use
install_name_tool to point to the correct version of libraries for any
specific build. This is what I first attempted, but just fixing one
library didn¹t do the job for me, as it then triggered another problem.
So, I really don¹t understand what it is that GRASS does, at runtime, that
SIP objects to.

It works for Michael (and me) for the "official" packages because we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation and
installation working using homebrew so that there is at least one way of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I
get
the following error:

,----
| bash-4.3$ less
/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd
/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
|
"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15
.3.0/scripts/d.rast.leg"
| != "" ] ; then
|
GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
win15.3.0/demolocation/.grassrc71
|
GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
arwin15.3.0
|
PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.
x86_64-apple-darwin15.3.0/scripts:$PATH"
|
PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app
le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5ar/
dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
|
DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86
_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/
dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-
1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-71201
60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/gra
ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
|
/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.
3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded:
/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.
dylib
| Referenced from:
|
/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.
3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a dynamic
library

(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn
.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is
incompatible
with Macports) So, I figured that I would just tried to install
grass7
using macports. It does seem to install, but the gui doesn¹t work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to the
GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d=C
wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8
wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h_V7mJ
Bf8t6V3mbREBfgUP8u90&e=

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does
that remind me of? Ah, yes - life."

- Marvin

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mailma
n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLt
SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rF
c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=

GRASS does not write to those SIP-restricted locations.

From what I've read, SIP also causes apps to ignore DYLD_LIBRARY_PATH, no matter where it points to. And the errors that have been reported point to it as well.

On Mar 15, 2016, at 3:06 PM, Adam Dershowitz <adershowitz@exponent.com> wrote:

On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
<grass-user-bounces@lists.osgeo.org on behalf of woklist@kyngchaos.com>
wrote:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
the in-compilation copies of the libraries so it can run the modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's
causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
so that everything within the GRASS app package looks directly inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry about it
because the extra dependencies that are bundled in the app are already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is easy) so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take, i.e. use
the generated binaries to generate the help files during installation?
Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I can
remember, it's nothing specific to OS X. Changing this would be major.

And then during installation change all the embedded library paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the right
place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step into a
separate make target
2) call the make target for help pages as a last step in the install
step?

This might make packaging more difficult, but wouldn't it make the whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem with
this.

It worked with Yosemite without problems. So this only needs to be done,
because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

I wonder if you can explain this anymore. Because, it is not at all clear
to me. DYLD_LIBRARY_PATH is something that is used all the time and works
fine in El Capitan for most Applications. The only thing that SIP
provides, if I understand correctly, is that it is not possible for an
application to write to /System /bin /sbin or /usr (and a few Apple
specifics in /Applications). Writing to /usr/local and /usr/lib should be
OK. Just having all the different versions of libraries around, and
dynamically finding them should work fine.
So, during run time, why does GRASS attempt to write to /usr (or one of
the other Apple owned folders? If it is using DYLD_LIBRARY_PATH to find
the necessary libraries from within the GRASS bundle, there should be no
need to write there.
Is it doing something unusual, such as at startup it tries to copy a few
files from the bundle to /usr so that it doesn¹t have to change
DYLD_LIBRARY_PATH? Even if that is the case, just changing those paths to
/usr/local would solve the SIP problem.

If the problem relates to how GRASS finds the correct version of
libraries, at least as a work around, it should be possible to use
install_name_tool to point to the correct version of libraries for any
specific build. This is what I first attempted, but just fixing one
library didn¹t do the job for me, as it then triggered another problem.
So, I really don¹t understand what it is that GRASS does, at runtime, that
SIP objects to.

It works for Michael (and me) for the "official" packages because we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation and
installation working using homebrew so that there is at least one way of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I
get
the following error:

,----
| bash-4.3$ less
/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd
/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
|
"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15
.3.0/scripts/d.rast.leg"
| != "" ] ; then
|
GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
win15.3.0/demolocation/.grassrc71
|
GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
arwin15.3.0
|
PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.
x86_64-apple-darwin15.3.0/scripts:$PATH"
|
PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app
le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5ar/
dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
|
DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86
_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/
dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-
1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-71201
60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/gra
ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
|
/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.
3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded:
/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.
dylib
| Referenced from:
|
/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.
3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a dynamic
library

(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn
.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is
incompatible
with Macports) So, I figured that I would just tried to install
grass7
using macports. It does seem to install, but the gui doesn¹t work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to the
GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d=C
wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8
wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h_V7mJ
Bf8t6V3mbREBfgUP8u90&e=

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does
that remind me of? Ah, yes - life."

- Marvin

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mailma
n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLt
SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rF
c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=

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

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

Got it. Now, based on that, I have found it. Apparently, it is for
protected processes:

https://developer.apple.com/library/mac/documentation/Security/Conceptual/S
ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

So, would it be possible to just just the paths that are used for the
search paths in the Application bundle itself?

-- Adam

On 3/15/16, 4:43 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

GRASS does not write to those SIP-restricted locations.

From what I've read, SIP also causes apps to ignore DYLD_LIBRARY_PATH, no
matter where it points to. And the errors that have been reported point
to it as well.

On Mar 15, 2016, at 3:06 PM, Adam Dershowitz <adershowitz@exponent.com>
wrote:

On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
<grass-user-bounces@lists.osgeo.org on behalf of woklist@kyngchaos.com>
wrote:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the
packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
the in-compilation copies of the libraries so it can run the modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's
causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
so that everything within the GRASS app package looks directly inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry about it
because the extra dependencies that are bundled in the app are
already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is easy)
so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take, i.e.
use
the generated binaries to generate the help files during installation?
Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I can
remember, it's nothing specific to OS X. Changing this would be major.

And then during installation change all the embedded library paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the right
place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step into a
separate make target
2) call the make target for help pages as a last step in the install
step?

This might make packaging more difficult, but wouldn't it make the
whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem
with
this.

It worked with Yosemite without problems. So this only needs to be
done,
because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

I wonder if you can explain this anymore. Because, it is not at all
clear
to me. DYLD_LIBRARY_PATH is something that is used all the time and
works
fine in El Capitan for most Applications. The only thing that SIP
provides, if I understand correctly, is that it is not possible for an
application to write to /System /bin /sbin or /usr (and a few Apple
specifics in /Applications). Writing to /usr/local and /usr/lib should
be
OK. Just having all the different versions of libraries around, and
dynamically finding them should work fine.
So, during run time, why does GRASS attempt to write to /usr (or one of
the other Apple owned folders? If it is using DYLD_LIBRARY_PATH to find
the necessary libraries from within the GRASS bundle, there should be no
need to write there.
Is it doing something unusual, such as at startup it tries to copy a few
files from the bundle to /usr so that it doesn¹t have to change
DYLD_LIBRARY_PATH? Even if that is the case, just changing those paths
to
/usr/local would solve the SIP problem.

If the problem relates to how GRASS finds the correct version of
libraries, at least as a work around, it should be possible to use
install_name_tool to point to the correct version of libraries for any
specific build. This is what I first attempted, but just fixing one
library didn¹t do the job for me, as it then triggered another problem.
So, I really don¹t understand what it is that GRASS does, at runtime,
that
SIP objects to.

It works for Michael (and me) for the "official" packages because we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation
and
installation working using homebrew so that there is at least one way
of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I
get
the following error:

,----
| bash-4.3$ less
/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd
/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
|

"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin
15
.3.0/scripts/d.rast.leg"
| != "" ] ; then
|

GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
ar
win15.3.0/demolocation/.grassrc71
|

GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple
-d
arwin15.3.0
|

PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
ar

win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64
-a

pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dis
t.
x86_64-apple-darwin15.3.0/scripts:$PATH"
|

PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
pp

le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5a
r/
dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
|

DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x
86

_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5a
r/

dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-4734
4-

1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-712
01

60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/g
ra
ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
5.
3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded:

/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.sv
n.
dylib
| Referenced from:
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
5.
3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a
dynamic
library

(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.s
vn
.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages
are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is
incompatible
with Macports) So, I figured that I would just tried to install
grass7
using macports. It does seem to install, but the gui doesn¹t
work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to
the
GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d
=C

wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rC
n8

wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h_V7
mJ
Bf8t6V3mbREBfgUP8u90&e=

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does
that remind me of? Ah, yes - life."

- Marvin

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mail
ma

n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
Lt

SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-
rF
c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mailm
an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4
CZvY&s=dFMvzAURv7ExJqKWuHhJuiWSp1tVxWAQLXdLERfRUcY&e=

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d=C
wIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8
wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwjWw1t
6syI0zj0Ou2szNtTSNWQ&e=

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

William Kyngesburye <woklist@kyngchaos.com> writes:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
the in-compilation copies of the libraries so it can run the modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's causing trouble in the app bundling.

So the correct approach would be to eliminate the use of
DYLD_LIBRARY_PATH completely from GRASS for the make process?

As the final grass executable does not sit in /bin or /usr/bin
(therefore not considered a "protected binary), DYLD_LIBRARY_PATH should
work. Correct? Maybe this is the reason, why Macports compiles
correctly, if it uses an own make?

Or is there a different solution?

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
so that everything within the GRASS app package looks directly inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry about it
because the extra dependencies that are bundled in the app are already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is easy) so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take, i.e. use
the generated binaries to generate the help files during installation?
Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I can
remember, it's nothing specific to OS X. Changing this would be
major.

OK - then it is here to stay.

And then during installation change all the embedded library paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the right
place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

OK.

Wouldn't it make sense to

1) split the generation of the help files from the build step into a
separate make target
2) call the make target for help pages as a last step in the install
step?

This might make packaging more difficult, but wouldn't it make the whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem with
this.

It worked with Yosemite without problems. So this only needs to be done,
because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

OK

It works for Michael (and me) for the "official" packages because we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation and
installation working using homebrew so that there is at least one way of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I get
the following error:

,----
| bash-4.3$ less /Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd /private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
| "/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts/d.rast.leg"
| != "" ] ; then
| GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/demolocation/.grassrc71
| GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0
| PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:$PATH"
| PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
| DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
| /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded:
| /usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib
| Referenced from:
| /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a dynamic
library
(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is incompatible
with Macports) So, I figured that I would just tried to install grass7
using macports. It does seem to install, but the gui doesn’t work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to the GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what
does that remind me of? Ah, yes - life."

- Marvin

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

Adam Dershowitz <adershowitz@exponent.com> writes:

Got it. Now, based on that, I have found it. Apparently, it is for
protected processes:

https://developer.apple.com/library/mac/documentation/Security/Conceptual/S
ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

Which seems to be the reason why during the make step (make is in
/usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is
ignored.

But when running GRASS, it should work.

Has anybody tried out to

1) disable SIP
2) compile GRASS from source
3) install GRASS
4) enable SIP

and does it run?

Do you know if Macports uses an own make (and possibly other tools?), or
the one supplied by OS X?

So, would it be possible to just just the paths that are used for the
search paths in the Application bundle itself?

-- Adam

On 3/15/16, 4:43 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

GRASS does not write to those SIP-restricted locations.

From what I've read, SIP also causes apps to ignore DYLD_LIBRARY_PATH, no
matter where it points to. And the errors that have been reported point
to it as well.

On Mar 15, 2016, at 3:06 PM, Adam Dershowitz <adershowitz@exponent.com>
wrote:

On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
<grass-user-bounces@lists.osgeo.org on behalf of woklist@kyngchaos.com>
wrote:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the
packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
the in-compilation copies of the libraries so it can run the modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's
causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
so that everything within the GRASS app package looks directly inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry about it
because the extra dependencies that are bundled in the app are
already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is easy)
so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take, i.e.
use
the generated binaries to generate the help files during installation?
Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I can
remember, it's nothing specific to OS X. Changing this would be major.

And then during installation change all the embedded library paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the right
place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step into a
separate make target
2) call the make target for help pages as a last step in the install
step?

This might make packaging more difficult, but wouldn't it make the
whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem
with
this.

It worked with Yosemite without problems. So this only needs to be
done,
because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

I wonder if you can explain this anymore. Because, it is not at all
clear
to me. DYLD_LIBRARY_PATH is something that is used all the time and
works
fine in El Capitan for most Applications. The only thing that SIP
provides, if I understand correctly, is that it is not possible for an
application to write to /System /bin /sbin or /usr (and a few Apple
specifics in /Applications). Writing to /usr/local and /usr/lib should
be
OK. Just having all the different versions of libraries around, and
dynamically finding them should work fine.
So, during run time, why does GRASS attempt to write to /usr (or one of
the other Apple owned folders? If it is using DYLD_LIBRARY_PATH to find
the necessary libraries from within the GRASS bundle, there should be no
need to write there.
Is it doing something unusual, such as at startup it tries to copy a few
files from the bundle to /usr so that it doesn¹t have to change
DYLD_LIBRARY_PATH? Even if that is the case, just changing those paths
to
/usr/local would solve the SIP problem.

If the problem relates to how GRASS finds the correct version of
libraries, at least as a work around, it should be possible to use
install_name_tool to point to the correct version of libraries for any
specific build. This is what I first attempted, but just fixing one
library didn¹t do the job for me, as it then triggered another problem.
So, I really don¹t understand what it is that GRASS does, at runtime,
that
SIP objects to.

It works for Michael (and me) for the "official" packages because we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation
and
installation working using homebrew so that there is at least one way
of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I
get
the following error:

,----
| bash-4.3$ less
/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd
/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
|

"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin
15
.3.0/scripts/d.rast.leg"
| != "" ] ; then
|

GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
ar
win15.3.0/demolocation/.grassrc71
|

GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple
-d
arwin15.3.0
|

PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
ar

win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64
-a

pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dis
t.
x86_64-apple-darwin15.3.0/scripts:$PATH"
|

PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
pp

le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5a
r/
dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
|

DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x
86

_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5a
r/

dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-4734
4-

1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-712
01

60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/g
ra
ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
5.
3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded:

/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.sv
n.
dylib
| Referenced from:
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
5.
3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a
dynamic
library

(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.s
vn
.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages
are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is
incompatible
with Macports) So, I figured that I would just tried to install
grass7
using macports. It does seem to install, but the gui doesn¹t
work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to
the
GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d
=C

wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rC
n8

wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h_V7
mJ
Bf8t6V3mbREBfgUP8u90&e=

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does
that remind me of? Ah, yes - life."

- Marvin

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mail
ma

n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
Lt

SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-
rF
c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mailm
an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4
CZvY&s=dFMvzAURv7ExJqKWuHhJuiWSp1tVxWAQLXdLERfRUcY&e=

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d=C
wIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8
wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwjWw1t
6syI0zj0Ou2szNtTSNWQ&e=

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

Got it. Now, based on that, I have found it. Apparently, it is for
protected processes:

https://developer.apple.com/library/mac/documentation/Security/Conceptual/S
ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

Which seems to be the reason why during the make step (make is in
/usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is
ignored.

But when running GRASS, it should work.

Has anybody tried out to

1) disable SIP
2) compile GRASS from source
3) install GRASS
4) enable SIP

and does it run?

Just tried it out, ant it works. So the DYLD_LIBRARY_PATH issue only
affects the compilation / installation of GRASS.

Do you know if Macports uses an own make (and possibly other tools?), or
the one supplied by OS X?

So, would it be possible to just just the paths that are used for the
search paths in the Application bundle itself?

-- Adam

On 3/15/16, 4:43 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

GRASS does not write to those SIP-restricted locations.

From what I've read, SIP also causes apps to ignore DYLD_LIBRARY_PATH, no
matter where it points to. And the errors that have been reported point
to it as well.

On Mar 15, 2016, at 3:06 PM, Adam Dershowitz <adershowitz@exponent.com>
wrote:

On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
<grass-user-bounces@lists.osgeo.org on behalf of woklist@kyngchaos.com>
wrote:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the
packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
the in-compilation copies of the libraries so it can run the modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's
causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
so that everything within the GRASS app package looks directly inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry about it
because the extra dependencies that are bundled in the app are
already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is easy)
so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take, i.e.
use
the generated binaries to generate the help files during installation?
Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I can
remember, it's nothing specific to OS X. Changing this would be major.

And then during installation change all the embedded library paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the right
place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step into a
separate make target
2) call the make target for help pages as a last step in the install
step?

This might make packaging more difficult, but wouldn't it make the
whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem
with
this.

It worked with Yosemite without problems. So this only needs to be
done,
because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

I wonder if you can explain this anymore. Because, it is not at all
clear
to me. DYLD_LIBRARY_PATH is something that is used all the time and
works
fine in El Capitan for most Applications. The only thing that SIP
provides, if I understand correctly, is that it is not possible for an
application to write to /System /bin /sbin or /usr (and a few Apple
specifics in /Applications). Writing to /usr/local and /usr/lib should
be
OK. Just having all the different versions of libraries around, and
dynamically finding them should work fine.
So, during run time, why does GRASS attempt to write to /usr (or one of
the other Apple owned folders? If it is using DYLD_LIBRARY_PATH to find
the necessary libraries from within the GRASS bundle, there should be no
need to write there.
Is it doing something unusual, such as at startup it tries to copy a few
files from the bundle to /usr so that it doesn¹t have to change
DYLD_LIBRARY_PATH? Even if that is the case, just changing those paths
to
/usr/local would solve the SIP problem.

If the problem relates to how GRASS finds the correct version of
libraries, at least as a work around, it should be possible to use
install_name_tool to point to the correct version of libraries for any
specific build. This is what I first attempted, but just fixing one
library didn¹t do the job for me, as it then triggered another problem.
So, I really don¹t understand what it is that GRASS does, at runtime,
that
SIP objects to.

It works for Michael (and me) for the "official" packages because we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation
and
installation working using homebrew so that there is at least one way
of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I
get
the following error:

,----
| bash-4.3$ less
/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd
/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
|

"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin
15
.3.0/scripts/d.rast.leg"
| != "" ] ; then
|

GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
ar
win15.3.0/demolocation/.grassrc71
|

GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple
-d
arwin15.3.0
|

PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
ar

win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64
-a

pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dis
t.
x86_64-apple-darwin15.3.0/scripts:$PATH"
|

PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
pp

le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5a
r/
dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
|

DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x
86

_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5a
r/

dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-4734
4-

1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-712
01

60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/g
ra
ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
5.
3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded:

/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.sv
n.
dylib
| Referenced from:
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
5.
3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a
dynamic
library

(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.s
vn
.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages
are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is
incompatible
with Macports) So, I figured that I would just tried to install
grass7
using macports. It does seem to install, but the gui doesn¹t
work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to
the
GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d
=C

wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rC
n8

wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h_V7
mJ
Bf8t6V3mbREBfgUP8u90&e=

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does
that remind me of? Ah, yes - life."

- Marvin

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mail
ma

n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
Lt

SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-
rF
c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mailm
an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4
CZvY&s=dFMvzAURv7ExJqKWuHhJuiWSp1tVxWAQLXdLERfRUcY&e=

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d=C
wIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8
wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwjWw1t
6syI0zj0Ou2szNtTSNWQ&e=

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

I've held off updating to make sure I could continue to provide binaries for the GRASS community. If you are right, I will upgrade one of my computers to the new OS and try this. SIP off and compile.

The question then is whether users need to turn SIP off to install in the normal applications folder.

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 Mar 16, 2016, at 12:24 PM, Rainer M Krug <Rainer@krugs.de> wrote:

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

Got it. Now, based on that, I have found it. Apparently, it is for
protected processes:

https://developer.apple.com/library/mac/documentation/Security/Conceptual/S
ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

Which seems to be the reason why during the make step (make is in
/usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is
ignored.

But when running GRASS, it should work.

Has anybody tried out to

1) disable SIP
2) compile GRASS from source
3) install GRASS
4) enable SIP

and does it run?

Just tried it out, ant it works. So the DYLD_LIBRARY_PATH issue only
affects the compilation / installation of GRASS.

Do you know if Macports uses an own make (and possibly other tools?), or
the one supplied by OS X?

So, would it be possible to just just the paths that are used for the
search paths in the Application bundle itself?

-- Adam

On 3/15/16, 4:43 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

GRASS does not write to those SIP-restricted locations.

From what I've read, SIP also causes apps to ignore DYLD_LIBRARY_PATH, no
matter where it points to. And the errors that have been reported point
to it as well.

On Mar 15, 2016, at 3:06 PM, Adam Dershowitz <adershowitz@exponent.com>
wrote:

On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
<grass-user-bounces@lists.osgeo.org on behalf of woklist@kyngchaos.com>
wrote:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the
packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
the in-compilation copies of the libraries so it can run the modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's
causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
so that everything within the GRASS app package looks directly inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry about it
because the extra dependencies that are bundled in the app are
already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is easy)
so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take, i.e.
use
the generated binaries to generate the help files during installation?
Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I can
remember, it's nothing specific to OS X. Changing this would be major.

And then during installation change all the embedded library paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the right
place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step into a
separate make target
2) call the make target for help pages as a last step in the install
step?

This might make packaging more difficult, but wouldn't it make the
whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem
with
this.

It worked with Yosemite without problems. So this only needs to be
done,
because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

I wonder if you can explain this anymore. Because, it is not at all
clear
to me. DYLD_LIBRARY_PATH is something that is used all the time and
works
fine in El Capitan for most Applications. The only thing that SIP
provides, if I understand correctly, is that it is not possible for an
application to write to /System /bin /sbin or /usr (and a few Apple
specifics in /Applications). Writing to /usr/local and /usr/lib should
be
OK. Just having all the different versions of libraries around, and
dynamically finding them should work fine.
So, during run time, why does GRASS attempt to write to /usr (or one of
the other Apple owned folders? If it is using DYLD_LIBRARY_PATH to find
the necessary libraries from within the GRASS bundle, there should be no
need to write there.
Is it doing something unusual, such as at startup it tries to copy a few
files from the bundle to /usr so that it doesn¹t have to change
DYLD_LIBRARY_PATH? Even if that is the case, just changing those paths
to
/usr/local would solve the SIP problem.

If the problem relates to how GRASS finds the correct version of
libraries, at least as a work around, it should be possible to use
install_name_tool to point to the correct version of libraries for any
specific build. This is what I first attempted, but just fixing one
library didn¹t do the job for me, as it then triggered another problem.
So, I really don¹t understand what it is that GRASS does, at runtime,
that
SIP objects to.

It works for Michael (and me) for the "official" packages because we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation
and
installation working using homebrew so that there is at least one way
of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I
get
the following error:

,----
| bash-4.3$ less
/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd
/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
|

"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin
15
.3.0/scripts/d.rast.leg"
| != "" ] ; then
|

GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
ar
win15.3.0/demolocation/.grassrc71
|

GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple
-d
arwin15.3.0
|

PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
ar

win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64
-a

pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dis
t.
x86_64-apple-darwin15.3.0/scripts:$PATH"
|

PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
pp

le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5a
r/
dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
|

DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x
86

_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5a
r/

dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-4734
4-

1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-712
01

60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/g
ra
ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
5.
3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded:

/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.sv
n.
dylib
| Referenced from:
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
5.
3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a
dynamic
library

(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.s
vn
.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages
are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is
incompatible
with Macports) So, I figured that I would just tried to install
grass7
using macports. It does seem to install, but the gui doesn¹t
work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to
the
GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d
=C

wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rC
n8

wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h_V7
mJ
Bf8t6V3mbREBfgUP8u90&e=

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does
that remind me of? Ah, yes - life."

- Marvin

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mail
ma

n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
Lt

SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-
rF
c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mailm
an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4
CZvY&s=dFMvzAURv7ExJqKWuHhJuiWSp1tVxWAQLXdLERfRUcY&e=

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d=C
wIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8
wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwjWw1t
6syI0zj0Ou2szNtTSNWQ&e=

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

On 3/16/16, 6:24 AM, "Rainer M Krug" <Rainer@krugs.de> wrote:

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

Got it. Now, based on that, I have found it. Apparently, it is for
protected processes:

https://developer.apple.com/library/mac/documentation/Security/Conceptua
l/S

ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.h
tml

Which seems to be the reason why during the make step (make is in
/usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is
ignored.

But when running GRASS, it should work.

Has anybody tried out to

1) disable SIP
2) compile GRASS from source
3) install GRASS
4) enable SIP

and does it run?

Just tried it out, ant it works. So the DYLD_LIBRARY_PATH issue only
affects the compilation / installation of GRASS.

Based on what you tried above I decided to try a different test: I just
disabled SIP, installed GRASS (from binaries), and then reenabled SIP and
found that it doesn’t work. So, the details of your compilation must be
different from that of the provided binaries. Yours are probably set for
just your computer (32/64 bit, OS version etc) while the binaries try to
work for everyone so make some of that determination at startup time.

Do you know if Macports uses an own make (and possibly other tools?), or
the one supplied by OS X?

I think that the answer is that by default macport uses the Apple provided
make, but specific ports can require other ports as dependencies. And
those can include things like gmake etc. So, some ports do require
non-Apple versions….
That said, the grass7 port lists:

Build Dependencies: pkgconfig
Library Dependencies: freetype, fftw-3, gdal, geos, tiff, libpng, proj,
cairo, readline, python27, py27-pillow, wxPython-3.0,
                      py27-wxPython-3.0

While any of those could then require other ports, they look pretty
standard, so likely just use Apple supplied make.

But, I am not completely sure that about other make tools that macports
could use, but I think that the above is correct.

So, would it be possible to just just the paths that are used for the
search paths in the Application bundle itself?

-- Adam

On 3/15/16, 4:43 PM, "William Kyngesburye" <woklist@kyngchaos.com>
wrote:

GRASS does not write to those SIP-restricted locations.

From what I've read, SIP also causes apps to ignore DYLD_LIBRARY_PATH,
no
matter where it points to. And the errors that have been reported
point
to it as well.

On Mar 15, 2016, at 3:06 PM, Adam Dershowitz
<adershowitz@exponent.com>
wrote:

On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
<grass-user-bounces@lists.osgeo.org on behalf of
woklist@kyngchaos.com>
wrote:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the
packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to
find
the in-compilation copies of the libraries so it can run the
modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's
causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in
packaging
so that everything within the GRASS app package looks directly
inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry
about it
because the extra dependencies that are bundled in the app are
already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at
the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is
easy)
so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to
make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take,
i.e.
use
the generated binaries to generate the help files during
installation?
Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I
can
remember, it's nothing specific to OS X. Changing this would be
major.

And then during installation change all the embedded library
paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the
right
place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step into
a
separate make target
2) call the make target for help pages as a last step in the
install
step?

This might make packaging more difficult, but wouldn't it make the
whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem
with
this.

It worked with Yosemite without problems. So this only needs to be
done,
because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

I wonder if you can explain this anymore. Because, it is not at all
clear
to me. DYLD_LIBRARY_PATH is something that is used all the time and
works
fine in El Capitan for most Applications. The only thing that SIP
provides, if I understand correctly, is that it is not possible for
an
application to write to /System /bin /sbin or /usr (and a few Apple
specifics in /Applications). Writing to /usr/local and /usr/lib
should
be
OK. Just having all the different versions of libraries around, and
dynamically finding them should work fine.
So, during run time, why does GRASS attempt to write to /usr (or one
of
the other Apple owned folders? If it is using DYLD_LIBRARY_PATH to
find
the necessary libraries from within the GRASS bundle, there should
be no
need to write there.
Is it doing something unusual, such as at startup it tries to copy a
few
files from the bundle to /usr so that it doesn¹t have to change
DYLD_LIBRARY_PATH? Even if that is the case, just changing those
paths
to
/usr/local would solve the SIP problem.

If the problem relates to how GRASS finds the correct version of
libraries, at least as a work around, it should be possible to use
install_name_tool to point to the correct version of libraries for
any
specific build. This is what I first attempted, but just fixing one
library didn¹t do the job for me, as it then triggered another
problem.
So, I really don¹t understand what it is that GRASS does, at runtime,
that
SIP objects to.

It works for Michael (and me) for the "official" packages because
we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation
and
installation working using homebrew so that there is at least one
way
of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de>
wrote:

I tried again to install 7.1 head without GUI using homwbrew,
and I
get
the following error:

,----
| bash-4.3$ less
/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd
/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
|

"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
win
15
.3.0/scripts/d.rast.leg"
| != "" ] ; then
|

GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-appl
e-d
ar
win15.3.0/demolocation/.grassrc71
|

GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-ap
ple
-d
arwin15.3.0
|

PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-appl
e-d
ar

win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86
_64
-a

pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/
dis
t.
x86_64-apple-darwin15.3.0/scripts:$PATH"
|

PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_6
4-a
pp

le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1yb
n5a
r/
dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
|

DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dis
t.x
86

_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1yb
n5a
r/

dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-4
734
4-

1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-
712
01

60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tm
p/g
ra
ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darw
in1
5.
3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded:

/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1
.sv
n.
dylib
| Referenced from:
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darw
in1
5.
3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a
dynamic
library

(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.
1.s
vn
.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages
are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is
incompatible
with Macports) So, I figured that I would just tried to
install
grass7
using macports. It does seem to install, but the gui doesn¹t
work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to
the
GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com
_&d
=C

wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn
6rC
n8

wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h
_V7
mJ
Bf8t6V3mbREBfgUP8u90&e=

"Oh, look, I seem to have fallen down a deep, dark hole. Now what
does
that remind me of? Ah, yes - life."

- Marvin

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_m
ail
ma

n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqX
abR
Lt

SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1b
up-
rF
c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_ma
ilm
an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqX
abR
LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_T
Of4
CZvY&s=dFMvzAURv7ExJqKWuHhJuiWSp1tVxWAQLXdLERfRUcY&e=

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&
d=C
wIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6r
Cn8
wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwjW
w1t
6syI0zj0Ou2szNtTSNWQ&e=

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

On 3/16/16, 9:03 AM, "Michael Barton" <Michael.Barton@asu.edu> wrote:

I've held off updating to make sure I could continue to provide binaries
for the GRASS community. If you are right, I will upgrade one of my
computers to the new OS and try this. SIP off and compile.

I hope that will work. But, I did just try to install your binaries
without SIP, then reenabled and it failed to run. Hopefully, your rebuild
will fix it.
FYI, I do really appreciate that you provide the binaries! Thank you.

The question then is whether users need to turn SIP off to install in the
normal applications folder.

No, they don’t. The vast majority of applications have not had any
problems transitioning to SIP. The only exceptions that I have heard of
having any problems are an application that tries to do some low-level
finder stuff (so it actually could be considered a real security risk) and
GRASS. Although, my sampling is far from complete!

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:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7E
cmbarton&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28T
aiOmWcn6rCn8wM&m=8a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs&s=brH8l8fvJcn
BOtKN-Iit46NVfqgp0TIE-1AzhSS-BOs&e= ,
https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=CwIGaQ&
c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=8
a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs&s=4QJPzCYG_0w7Wr4CmDr_AQ1GzmaYY
SRUHhN3ywKiNnk&e=

On Mar 16, 2016, at 12:24 PM, Rainer M Krug <Rainer@krugs.de> wrote:

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

Got it. Now, based on that, I have found it. Apparently, it is for

protected processes:

https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.co
m_library_mac_documentation_Security_Conceptual_S&d=CwIGaQ&c=t0wRGL5ICV
zH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=8a8vJwN3CL
QA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs&s=lpyQ9k04zOgM7WEr5IuYKSvzyOXTxIPvKFF
p5HLGOCU&e=

ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.
html

Which seems to be the reason why during the make step (make is in

/usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is

ignored.

But when running GRASS, it should work.

Has anybody tried out to

1) disable SIP

2) compile GRASS from source

3) install GRASS

4) enable SIP

and does it run?

Just tried it out, ant it works. So the DYLD_LIBRARY_PATH issue only

affects the compilation / installation of GRASS.

Do you know if Macports uses an own make (and possibly other tools?),
or

the one supplied by OS X?

So, would it be possible to just just the paths that are used for the

search paths in the Application bundle itself?

-- Adam

On 3/15/16, 4:43 PM, "William Kyngesburye" <woklist@kyngchaos.com>
wrote:

GRASS does not write to those SIP-restricted locations.

From what I've read, SIP also causes apps to ignore
DYLD_LIBRARY_PATH, no

matter where it points to. And the errors that have been reported
point

to it as well.

On Mar 15, 2016, at 3:06 PM, Adam Dershowitz
<adershowitz@exponent.com>

wrote:

On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"

<grass-user-bounces@lists.osgeo.org on behalf of
woklist@kyngchaos.com>

wrote:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the

packaging

issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to
find

the in-compilation copies of the libraries so it can run the
modules

to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and
not

during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's

causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in
packaging

so that everything within the GRASS app package looks directly
inside

the package for libraries and not rely on DYLD_LIBRARY_PATH.

Homebrew, Macports and /usr/local builds don't need to worry
about it

because the extra dependencies that are bundled in the app are

already

in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at
the

moment only the one you discuss below.

The compilation issue needs work to compile all libraries with
the

temporary path inside the libraries and modules (this part is
easy)

so

that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to
make

GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take,
i.e.

use

the generated binaries to generate the help files during
installation?

Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I
can

remember, it's nothing specific to OS X. Changing this would be
major.

And then during installation change all the embedded library
paths to

the final destination (this is harder, to figure out the complex

makefile include system of GRASS to get this operation in the
right

place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step
into a

separate make target

2) call the make target for help pages as a last step in the
install

step?

This might make packaging more difficult, but wouldn't it make the

whole

process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem

with

this.

It worked with Yosemite without problems. So this only needs to be

done,

because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

I wonder if you can explain this anymore. Because, it is not at all

clear

to me. DYLD_LIBRARY_PATH is something that is used all the time and

works

fine in El Capitan for most Applications. The only thing that SIP

provides, if I understand correctly, is that it is not possible for
an

application to write to /System /bin /sbin or /usr (and a few Apple

specifics in /Applications). Writing to /usr/local and /usr/lib
should

be

OK. Just having all the different versions of libraries around, and

dynamically finding them should work fine.

So, during run time, why does GRASS attempt to write to /usr (or
one of

the other Apple owned folders? If it is using DYLD_LIBRARY_PATH to
find

the necessary libraries from within the GRASS bundle, there should
be no

need to write there.

Is it doing something unusual, such as at startup it tries to copy
a few

files from the bundle to /usr so that it doesn¹t have to change

DYLD_LIBRARY_PATH? Even if that is the case, just changing those
paths

to

/usr/local would solve the SIP problem.

If the problem relates to how GRASS finds the correct version of

libraries, at least as a work around, it should be possible to use

install_name_tool to point to the correct version of libraries for
any

specific build. This is what I first attempted, but just fixing one

library didn¹t do the job for me, as it then triggered another
problem.

So, I really don¹t understand what it is that GRASS does, at
runtime,

that

SIP objects to.

It works for Michael (and me) for the "official" packages
because we

compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the
compilation

and

installation working using homebrew so that there is at least one
way

of

t=running GRASS on El Capitan without having to interfere with the

security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de>
wrote:

I tried again to install 7.1 head without GUI using homwbrew,
and I

get

the following error:

,----

| bash-4.3$ less

/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make

| bash-4.3$ cd

/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg

| bash-4.3$ ls

| Makefile d.rast.leg.html d.rast.leg.py

| bash-4.3$ make

| if [

|

"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-da
rwin

15

.3.0/scripts/d.rast.leg"

| != "" ] ; then

|

GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app
le-d

ar

win15.3.0/demolocation/.grassrc71

|

GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
pple

-d

arwin15.3.0

|

PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app
le-d

ar

win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x8
6_64

-a

pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar
/dis

t.

x86_64-apple-darwin15.3.0/scripts:$PATH"

|

PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_
64-a

pp

le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1y
bn5a

r/

dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"

|

DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/di
st.x

86

_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1y
bn5a

r/

dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-
4734

4-

1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass
-712

01

60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/t
mp/g

ra

ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"

| LC_ALL=C

|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
win1

5.

3.0/scripts/d.rast.leg

| --html-description < /dev/null | grep -v '</body>\|</html>' >

| d.rast.leg.tmp.html ; fi

| dyld: Library not loaded:

/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.
1.sv

n.

dylib

| Referenced from:

|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
win1

5.

3.0/bin/g.parser

| Reason: image not found

| make: *** [d.rast.leg.tmp.html] Error 1

| rm d.rast.leg.tmp.html

| bash-4.3$

`----

In other words: grass is looking during the compilation for a

dynamic

library

(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7
.1.s

vn

.dylib)

which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual
pages

are

created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is

incompatible

with Macports) So, I figured that I would just tried to
install

grass7

using macports. It does seem to install, but the gui doesn¹t

work:

$grass70

Cleaning up temporary files...

Starting GRASS GIS...

ERROR: wxGUI requires wxPython. No module named wxversion

Error in GUI startup. If necessary, please report this error
to

the

GRASS

developers.

Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.

But, it seems like this is a different problem.

-----

William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.co
m_&d

=C

wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWc
n6rC

n8

wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1
h_V7

mJ

Bf8t6V3mbREBfgUP8u90&e=

"Oh, look, I seem to have fallen down a deep, dark hole. Now what
does

that remind me of? Ah, yes - life."

- Marvin

_______________________________________________

grass-user mailing list

grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_
mail

ma

n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGq
XabR

Lt

SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1
bup-

rF

c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=

_______________________________________________

grass-user mailing list

grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_m
ailm

an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGq
XabR

LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_
TOf4

CZvY&s=dFMvzAURv7ExJqKWuHhJuiWSp1tVxWAQLXdLERfRUcY&e=

-----

William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_
&d=C

wIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6
rCn8

wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwj
Ww1t

6syI0zj0Ou2szNtTSNWQ&e=

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

_______________________________________________

grass-user mailing list

grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mai
lman_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGq
XabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=8a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa
_5GDDVCFJs&s=zeHh0C0suAsouujRlhHjO0snRjDR9Ga2pfaXnh60h0E&e=

--

Rainer M. Krug

email: Rainer<at>krugs<dot>de

PGP: 0x0F52F982

Why it's working for Rainer's compiled GRASS at runtime is because all the GRASS libraries and executables and dependencies have the same embedded paths as where they are installed. DYLD_LIBRARY_PATH is still ignored from SIP, but it's not needed.

The binary app install has the extras with different paths from where they are bundled in the GRASS app. Whatever you do with SIP for install does not matter, if SIP is on when the GRASS app is run it will fail.

On Mar 16, 2016, at 8:03 AM, Adam Dershowitz <adershowitz@exponent.com> wrote:

On 3/16/16, 6:24 AM, "Rainer M Krug" <Rainer@krugs.de> wrote:

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

Got it. Now, based on that, I have found it. Apparently, it is for
protected processes:

https://developer.apple.com/library/mac/documentation/Security/Conceptua
l/S

ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.h
tml

Which seems to be the reason why during the make step (make is in
/usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is
ignored.

But when running GRASS, it should work.

Has anybody tried out to

1) disable SIP
2) compile GRASS from source
3) install GRASS
4) enable SIP

and does it run?

Just tried it out, ant it works. So the DYLD_LIBRARY_PATH issue only
affects the compilation / installation of GRASS.

Based on what you tried above I decided to try a different test: I just
disabled SIP, installed GRASS (from binaries), and then reenabled SIP and
found that it doesn’t work. So, the details of your compilation must be
different from that of the provided binaries. Yours are probably set for
just your computer (32/64 bit, OS version etc) while the binaries try to
work for everyone so make some of that determination at startup time.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy

Michael Barton <Michael.Barton@asu.edu> writes:

I've held off updating to make sure I could continue to provide
binaries for the GRASS community. If you are right, I will upgrade one
of my computers to the new OS and try this. SIP off and compile.

Pleas note that I used homebrew to install.

As William mentions in his email
http://permalink.gmane.org/gmane.comp.gis.grass.user/53067 :

,----
| Why it's working for Rainer's compiled GRASS at runtime is because all
| the GRASS libraries and executables and dependencies have the same
| embedded paths as where they are installed. DYLD_LIBRARY_PATH is
| still ignored from SIP, but it's not needed.
`----

I can't speak for the binary app here (.dmg).

Concerning homebrew: they provide so called "bottles" which are
binaries. I *think* that one could create a bottle of GRASS, and it
could be installed by everybody without having to go through the SIP
disable - compile - enable shlep. But this would only apply to the
default set of config options.

My main question is now: can we get rid of DYLD_LIBRARY_PATH for
*compiling*? This would make GRASS compilable again on El Capitan with homebrew.

Any suggestions?

Rainer

P.S: there seems to quite a group of developers out there who say in
general that DYLD_LIBRARY_PATH and DYLD_... are bad and should be
avoided. Would that be possible for GRASS, or require a large amount of work?

The question then is whether users need to turn SIP off to install in the normal applications folder.

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 Mar 16, 2016, at 12:24 PM, Rainer M Krug <Rainer@krugs.de> wrote:

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

Got it. Now, based on that, I have found it. Apparently, it is for
protected processes:

https://developer.apple.com/library/mac/documentation/Security/Conceptual/S
ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

Which seems to be the reason why during the make step (make is in
/usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is
ignored.

But when running GRASS, it should work.

Has anybody tried out to

1) disable SIP
2) compile GRASS from source
3) install GRASS
4) enable SIP

and does it run?

Just tried it out, ant it works. So the DYLD_LIBRARY_PATH issue only
affects the compilation / installation of GRASS.

Do you know if Macports uses an own make (and possibly other tools?), or
the one supplied by OS X?

So, would it be possible to just just the paths that are used for the
search paths in the Application bundle itself?

-- Adam

On 3/15/16, 4:43 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

GRASS does not write to those SIP-restricted locations.

From what I've read, SIP also causes apps to ignore DYLD_LIBRARY_PATH, no
matter where it points to. And the errors that have been reported point
to it as well.

On Mar 15, 2016, at 3:06 PM, Adam Dershowitz <adershowitz@exponent.com>
wrote:

On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
<grass-user-bounces@lists.osgeo.org on behalf of woklist@kyngchaos.com>
wrote:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the
packaging
issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
the in-compilation copies of the libraries so it can run the modules
to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and not
during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's
causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
so that everything within the GRASS app package looks directly inside
the package for libraries and not rely on DYLD_LIBRARY_PATH.
Homebrew, Macports and /usr/local builds don't need to worry about it
because the extra dependencies that are bundled in the app are
already
in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at the
moment only the one you discuss below.

The compilation issue needs work to compile all libraries with the
temporary path inside the libraries and modules (this part is easy)
so
that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to make
GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take, i.e.
use
the generated binaries to generate the help files during installation?
Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I can
remember, it's nothing specific to OS X. Changing this would be major.

And then during installation change all the embedded library paths to
the final destination (this is harder, to figure out the complex
makefile include system of GRASS to get this operation in the right
place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step into a
separate make target
2) call the make target for help pages as a last step in the install
step?

This might make packaging more difficult, but wouldn't it make the
whole
process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem
with
this.

It worked with Yosemite without problems. So this only needs to be
done,
because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

I wonder if you can explain this anymore. Because, it is not at all
clear
to me. DYLD_LIBRARY_PATH is something that is used all the time and
works
fine in El Capitan for most Applications. The only thing that SIP
provides, if I understand correctly, is that it is not possible for an
application to write to /System /bin /sbin or /usr (and a few Apple
specifics in /Applications). Writing to /usr/local and /usr/lib should
be
OK. Just having all the different versions of libraries around, and
dynamically finding them should work fine.
So, during run time, why does GRASS attempt to write to /usr (or one of
the other Apple owned folders? If it is using DYLD_LIBRARY_PATH to find
the necessary libraries from within the GRASS bundle, there should be no
need to write there.
Is it doing something unusual, such as at startup it tries to copy a few
files from the bundle to /usr so that it doesn¹t have to change
DYLD_LIBRARY_PATH? Even if that is the case, just changing those paths
to
/usr/local would solve the SIP problem.

If the problem relates to how GRASS finds the correct version of
libraries, at least as a work around, it should be possible to use
install_name_tool to point to the correct version of libraries for any
specific build. This is what I first attempted, but just fixing one
library didn¹t do the job for me, as it then triggered another problem.
So, I really don¹t understand what it is that GRASS does, at runtime,
that
SIP objects to.

It works for Michael (and me) for the "official" packages because we
compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the compilation
and
installation working using homebrew so that there is at least one way
of
t=running GRASS on El Capitan without having to interfere with the
security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de> wrote:

I tried again to install 7.1 head without GUI using homwbrew, and I
get
the following error:

,----
| bash-4.3$ less
/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
| bash-4.3$ cd
/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
| bash-4.3$ ls
| Makefile d.rast.leg.html d.rast.leg.py
| bash-4.3$ make
| if [
|

"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin
15
.3.0/scripts/d.rast.leg"
| != "" ] ; then
|

GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
ar
win15.3.0/demolocation/.grassrc71
|

GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple
-d
arwin15.3.0
|

PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
ar

win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64
-a

pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dis
t.
x86_64-apple-darwin15.3.0/scripts:$PATH"
|

PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
pp

le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5a
r/
dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
|

DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x
86

_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5a
r/

dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-4734
4-

1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-712
01

60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/g
ra
ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
| LC_ALL=C
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
5.
3.0/scripts/d.rast.leg
| --html-description < /dev/null | grep -v '</body>\|</html>' >
| d.rast.leg.tmp.html ; fi
| dyld: Library not loaded:

/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.sv
n.
dylib
| Referenced from:
|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
5.
3.0/bin/g.parser
| Reason: image not found
| make: *** [d.rast.leg.tmp.html] Error 1
| rm d.rast.leg.tmp.html
| bash-4.3$
`----

In other words: grass is looking during the compilation for a
dynamic
library

(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.s
vn
.dylib)
which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual pages
are
created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is
incompatible
with Macports) So, I figured that I would just tried to install
grass7
using macports. It does seem to install, but the gui doesn¹t
work:

$grass70
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to
the
GRASS
developers.
Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.
But, it seems like this is a different problem.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d
=C

wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rC
n8

wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h_V7
mJ
Bf8t6V3mbREBfgUP8u90&e=

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does
that remind me of? Ah, yes - life."

- Marvin

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mail
ma

n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
Lt

SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-
rF
c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mailm
an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4
CZvY&s=dFMvzAURv7ExJqKWuHhJuiWSp1tVxWAQLXdLERfRUcY&e=

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d=C
wIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8
wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwjWw1t
6syI0zj0Ou2szNtTSNWQ&e=

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

Adam Dershowitz <adershowitz@exponent.com> writes:

On 3/16/16, 9:03 AM, "Michael Barton" <Michael.Barton@asu.edu> wrote:

I've held off updating to make sure I could continue to provide binaries
for the GRASS community. If you are right, I will upgrade one of my
computers to the new OS and try this. SIP off and compile.

I hope that will work. But, I did just try to install your binaries
without SIP, then reenabled and it failed to run. Hopefully, your rebuild
will fix it.

According to Williams email, not (
http://permalink.gmane.org/gmane.comp.gis.grass.user/53067 )

FYI, I do really appreciate that you provide the binaries! Thank you.

The question then is whether users need to turn SIP off to install in the
normal applications folder.

No, they don’t. The vast majority of applications have not had any
problems transitioning to SIP. The only exceptions that I have heard of
having any problems are an application that tries to do some low-level
finder stuff (so it actually could be considered a real security risk) and
GRASS. Although, my sampling is far from complete!

I have exactly the same impression.

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:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7E
cmbarton&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28T
aiOmWcn6rCn8wM&m=8a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs&s=brH8l8fvJcn
BOtKN-Iit46NVfqgp0TIE-1AzhSS-BOs&e= ,
https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=CwIGaQ&
c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=8
a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs&s=4QJPzCYG_0w7Wr4CmDr_AQ1GzmaYY
SRUHhN3ywKiNnk&e=

On Mar 16, 2016, at 12:24 PM, Rainer M Krug <Rainer@krugs.de> wrote:

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

Got it. Now, based on that, I have found it. Apparently, it is for

protected processes:

https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.co
m_library_mac_documentation_Security_Conceptual_S&d=CwIGaQ&c=t0wRGL5ICV
zH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=8a8vJwN3CL
QA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs&s=lpyQ9k04zOgM7WEr5IuYKSvzyOXTxIPvKFF
p5HLGOCU&e=

ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.
html

Which seems to be the reason why during the make step (make is in

/usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is

ignored.

But when running GRASS, it should work.

Has anybody tried out to

1) disable SIP

2) compile GRASS from source

3) install GRASS

4) enable SIP

and does it run?

Just tried it out, ant it works. So the DYLD_LIBRARY_PATH issue only

affects the compilation / installation of GRASS.

Do you know if Macports uses an own make (and possibly other tools?),
or

the one supplied by OS X?

So, would it be possible to just just the paths that are used for the

search paths in the Application bundle itself?

-- Adam

On 3/15/16, 4:43 PM, "William Kyngesburye" <woklist@kyngchaos.com>
wrote:

GRASS does not write to those SIP-restricted locations.

From what I've read, SIP also causes apps to ignore
DYLD_LIBRARY_PATH, no

matter where it points to. And the errors that have been reported
point

to it as well.

On Mar 15, 2016, at 3:06 PM, Adam Dershowitz
<adershowitz@exponent.com>

wrote:

On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"

<grass-user-bounces@lists.osgeo.org on behalf of
woklist@kyngchaos.com>

wrote:

On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer@krugs.de> wrote:

William Kyngesburye <woklist@kyngchaos.com> writes:

This is also a known issue, related to but separate from the

packaging

issue. During compilation, GRASS also uses DYLD_LIBRARY_PATH to
find

the in-compilation copies of the libraries so it can run the
modules

to create the help files.

OK - this aligns with what I guessed from the error messages.

So the DYLD_LIBRARY_PATH is only used during compilation - and
not

during execution, even without "make install"?

No, DYLD_LIBRARY_PATH is also used during execution, that's what's

causing trouble in the app bundling.

The packaging issue with DYLD_LIBRARY_PATH can be fixed in
packaging

so that everything within the GRASS app package looks directly
inside

the package for libraries and not rely on DYLD_LIBRARY_PATH.

Homebrew, Macports and /usr/local builds don't need to worry
about it

because the extra dependencies that are bundled in the app are

already

in their proper place.

OK - so in homebrew (I can't speak for Macports) the issue is at
the

moment only the one you discuss below.

The compilation issue needs work to compile all libraries with
the

temporary path inside the libraries and modules (this part is
easy)

so

that during compilation help file generation works.

OK - so can you give me any suggestions how I can solve this to
make

GRASS at least compile on homebrew?

Speaking generally - is this really the right approach to take,
i.e.

use

the generated binaries to generate the help files during
installation?

Wouldn't it be much easier to do this during installation?

Well, the compilation approach is how it's been done as long as I
can

remember, it's nothing specific to OS X. Changing this would be
major.

And then during installation change all the embedded library
paths to

the final destination (this is harder, to figure out the complex

makefile include system of GRASS to get this operation in the
right

place).

The paths are in the grass script file? Or in others as well?

No, the paths are embedded in the libraries and binary executables.

Wouldn't it make sense to

1) split the generation of the help files from the build step
into a

separate make target

2) call the make target for help pages as a last step in the
install

step?

This might make packaging more difficult, but wouldn't it make the

whole

process clearer?

Homebrew, Macports, /usr/local AND app installs do have a problem

with

this.

It worked with Yosemite without problems. So this only needs to be

done,

because of the issues you describe above?

It's specifically an El Capitan+ issue, because of SIP.

I wonder if you can explain this anymore. Because, it is not at all

clear

to me. DYLD_LIBRARY_PATH is something that is used all the time and

works

fine in El Capitan for most Applications. The only thing that SIP

provides, if I understand correctly, is that it is not possible for
an

application to write to /System /bin /sbin or /usr (and a few Apple

specifics in /Applications). Writing to /usr/local and /usr/lib
should

be

OK. Just having all the different versions of libraries around, and

dynamically finding them should work fine.

So, during run time, why does GRASS attempt to write to /usr (or
one of

the other Apple owned folders? If it is using DYLD_LIBRARY_PATH to
find

the necessary libraries from within the GRASS bundle, there should
be no

need to write there.

Is it doing something unusual, such as at startup it tries to copy
a few

files from the bundle to /usr so that it doesn¹t have to change

DYLD_LIBRARY_PATH? Even if that is the case, just changing those
paths

to

/usr/local would solve the SIP problem.

If the problem relates to how GRASS finds the correct version of

libraries, at least as a work around, it should be possible to use

install_name_tool to point to the correct version of libraries for
any

specific build. This is what I first attempted, but just fixing one

library didn¹t do the job for me, as it then triggered another
problem.

So, I really don¹t understand what it is that GRASS does, at
runtime,

that

SIP objects to.

It works for Michael (and me) for the "official" packages
because we

compile on older systems that don't have SIP.

Thanks for these clarifications.

I would very much appreciate if we could see to get the
compilation

and

installation working using homebrew so that there is at least one
way

of

t=running GRASS on El Capitan without having to interfere with the

security settings.

Thanks,

Rainer

On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer@krugs.de>
wrote:

I tried again to install 7.1 head without GUI using homwbrew,
and I

get

the following error:

,----

| bash-4.3$ less

/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make

| bash-4.3$ cd

/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg

| bash-4.3$ ls

| Makefile d.rast.leg.html d.rast.leg.py

| bash-4.3$ make

| if [

|

"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-da
rwin

15

.3.0/scripts/d.rast.leg"

| != "" ] ; then

|

GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app
le-d

ar

win15.3.0/demolocation/.grassrc71

|

GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
pple

-d

arwin15.3.0

|

PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app
le-d

ar

win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x8
6_64

-a

pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar
/dis

t.

x86_64-apple-darwin15.3.0/scripts:$PATH"

|

PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_
64-a

pp

le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1y
bn5a

r/

dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"

|

DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/di
st.x

86

_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1y
bn5a

r/

dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-
4734

4-

1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass
-712

01

60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/t
mp/g

ra

ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"

| LC_ALL=C

|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
win1

5.

3.0/scripts/d.rast.leg

| --html-description < /dev/null | grep -v '</body>\|</html>' >

| d.rast.leg.tmp.html ; fi

| dyld: Library not loaded:

/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.
1.sv

n.

dylib

| Referenced from:

|

/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
win1

5.

3.0/bin/g.parser

| Reason: image not found

| make: *** [d.rast.leg.tmp.html] Error 1

| rm d.rast.leg.tmp.html

| bash-4.3$

`----

In other words: grass is looking during the compilation for a

dynamic

library

(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7
.1.s

vn

.dylib)

which has been created, but will only be there when installing.

Also important: this error only occurs when the html manual
pages

are

created!

Cheers,

Rainer

Rainer M Krug <Rainer@krugs.de> writes:

Adam Dershowitz <adershowitz@exponent.com> writes:

I use Macports for a bunch of other things (and Homebrew is

incompatible

with Macports) So, I figured that I would just tried to
install

grass7

using macports. It does seem to install, but the gui doesn¹t

work:

$grass70

Cleaning up temporary files...

Starting GRASS GIS...

ERROR: wxGUI requires wxPython. No module named wxversion

Error in GUI startup. If necessary, please report this error
to

the

GRASS

developers.

Switching to text mode now.

I don't use MacPorts - but can you try to install without GUI?

Hit RETURN to continue...

This is odd, since wxpython is installed.

But, it seems like this is a different problem.

-----

William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.co
m_&d

=C

wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWc
n6rC

n8

wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1
h_V7

mJ

Bf8t6V3mbREBfgUP8u90&e=

"Oh, look, I seem to have fallen down a deep, dark hole. Now what
does

that remind me of? Ah, yes - life."

- Marvin

_______________________________________________

grass-user mailing list

grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_
mail

ma

n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGq
XabR

Lt

SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1
bup-

rF

c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=

_______________________________________________

grass-user mailing list

grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_m
ailm

an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGq
XabR

LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_
TOf4

CZvY&s=dFMvzAURv7ExJqKWuHhJuiWSp1tVxWAQLXdLERfRUcY&e=

-----

William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_
&d=C

wIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6
rCn8

wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwj
Ww1t

6syI0zj0Ou2szNtTSNWQ&e=

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

_______________________________________________

grass-user mailing list

grass-user@lists.osgeo.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mai
lman_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGq
XabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=8a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa
_5GDDVCFJs&s=zeHh0C0suAsouujRlhHjO0snRjDR9Ga2pfaXnh60h0E&e=

--

Rainer M. Krug

email: Rainer<at>krugs<dot>de

PGP: 0x0F52F982

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

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982