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

[Michael Barton]

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  wrote:
> 
> Rainer M Krug  writes:
> 
>> Adam Dershowitz  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"  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 
> wrote:
> 
> 
> 
> 
> 
> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
> 
> wrote:
> 
>> On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
>>> 
>>> William Kyngesburye  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 t

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

[Rainer M Krug]

Adam Dershowitz  writes:

> On 3/16/16, 9:03 AM, "Michael Barton"  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  wrote:
>>
>>> 
>>
>>> Rainer M Krug  writes:
>>
>>> 
>>
 Adam Dershowitz  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" 
>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
>>>
>>
>>> wrote:
>>
>>> 
>>
>>> 
>>
>>> 
>>
>>> 
>>
>>> 
>>
>>> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
>>
>>> >>wokl...@kyngchaos.com>
>>
>>> wrote:
>>
>>> 
>>
 On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
>>
> 
>>
> William Kyngesburye  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

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

[Adam Dershowitz]

On 3/16/16, 6:24 AM, "Rainer M Krug"  wrote:

>Rainer M Krug  writes:
>
>> Adam Dershowitz  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" 
>>>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
>
>wrote:
> 
> 
> 
> 
> 
> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
> wokl...@kyngchaos.com>
> wrote:
> 
>> On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
>>> 
>>> William Kyngesburye  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

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

[Adam Dershowitz]

On 3/16/16, 9:03 AM, "Michael Barton"  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  wrote:
>
>> 
>
>> Rainer M Krug  writes:
>
>> 
>
>>> Adam Dershowitz  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" 
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
>>
>
>> wrote:
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
>
>> >wokl...@kyngchaos.com>
>
>> wrote:
>
>> 
>
>>> On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
>
 
>
 William Kyngesburye  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 fi

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

[Rainer M Krug]

Michael Barton  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  wrote:
>> 
>> Rainer M Krug  writes:
>> 
>>> Adam Dershowitz  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"  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 
>> wrote:
>> 
>> 
>> 
>> 
>> 
>> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
>> 
>> wrote:
>> 
>>> On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
 
 William Kyngesburye  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
>>>

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

[William Kyngesburye]

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  wrote:
> 
> 
> On 3/16/16, 6:24 AM, "Rainer M Krug"  wrote:
> 
>> Rainer M Krug  writes:
>> 
>>> Adam Dershowitz  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 
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

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

[Rainer M Krug]

Rainer M Krug  writes:

> Adam Dershowitz  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"  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 
wrote:
 
 
 
 
 
 On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
 
 wrote:
 
> On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
>> 
>> William Kyngesburye  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 

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

[Rainer M Krug]

Adam Dershowitz  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"  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 
>>>wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
>>> 
>>> wrote:
>>> 
 On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
> 
> William Kyngesburye  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 

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

[Rainer M Krug]

William Kyngesburye  writes:

> On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
>> 
>> William Kyngesburye  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  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
 | Makefiled.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.

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

[Adam Dershowitz]

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"  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 
>>wrote:
>> 
>> 
>> 
>> 
>> 
>> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
>> 
>> wrote:
>> 
>>> On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
 
 William Kyngesburye  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 a

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

[William Kyngesburye]

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  wrote:
> 
> 
> 
> 
> 
> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
> 
> wrote:
> 
>> On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
>>> 
>>> William Kyngesburye  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 apprecia

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

[Adam Dershowitz]

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

wrote:

>On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
>> 
>> William Kyngesburye  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  wrote:
 
 
 I tried again to install 7.1 head without GUI using homwbrew, and I
get
 the following error:
 
>>

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

[William Kyngesburye]

On Mar 15, 2016, at 2:05 PM, Rainer M Krug  wrote:
> 
> William Kyngesburye  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  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
>>> | Makefiled.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
>>> 

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

[Rainer M Krug]

Adam Dershowitz  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"  wrote:
>
>>Adam Dershowitz  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"  wrote:
>>>
Michael Barton  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
>  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
>  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/-0001-5073-5572
> 
> 
> 

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

[Rainer M Krug]

William Kyngesburye  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  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
>> | Makefiled.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 '\|' >
>> | 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/libgras

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

[Adam Dershowitz]

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"  wrote:

>Adam Dershowitz  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"  wrote:
>>
>>>Michael Barton  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
  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
  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/-0001-5073-5572
 
 
 Can’t stop the signal.


>>>
>>>-- 
>>>Rainer M. Krug
>>>email: Rainerkrugsde
>>>PGP: 0x0F52F982
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>-- 
>Rainer M. Krug
>email: R

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

[William Kyngesburye]

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  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
> | Makefiled.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 '\|' > 
> 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  writes:
> 
>> Adam Dershowitz  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 
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@li

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

[Rainer M Krug]

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
| Makefiled.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 '\|' > 
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  writes:

> Adam Dershowitz  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"  wrote:
>>
>>>Michael Barton  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
  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. P

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

[Rainer M Krug]

Adam Dershowitz  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"  wrote:
>
>>Michael Barton  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
>>>  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
>>>  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/-0001-5073-5572
>>> 
>>> 
>>> Can’t stop the signal.
>>>
>>>
>>
>>-- 
>>Rainer M. Krug
>>email: Rainerkrugsde
>>PGP: 0x0F52F982
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Adam Dershowitz]

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.


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"  wrote:

>Michael Barton  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
>>  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
>>  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/-0001-5073-5572
>> 
>> 
>> Can’t stop the signal.
>>
>>
>
>-- 
>Rainer M. Krug
>email: Rainerkrugsde
>PGP: 0x0F52F982

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

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

[Adam Dershowitz]

I don’t understand why that should matter.  It Is great that it is packaged 
with the whole combination to run in different configurations.  But, does GRASS 
then write to /usr at runtime?  Can’t it just run the correct library from in 
the Application package?
Or is there something about SIP beyond protection against writing to a few key 
folders?
Just to be clear, I’m not trying to be the last bit accusatory, but I’m just 
curious about understanding the problem.  If all of the correct included 
versions of libraries are included in the application package, then the issue 
should just be about pointing to the correct dynamic libraries.  Why should SIP 
care about that at all?

-- Adam


From: Michael Barton mailto:michael.bar...@asu.edu>>
Date: Tuesday, March 15, 2016 at 9:36 AM
To: Carlos Guâno Grohmann 
mailto:carlos.grohm...@gmail.com>>
Cc: Adam Dershowitz 
mailto:adershow...@exponent.com>>, Rainer M Krug 
mailto:rai...@krugs.de>>, grass-user grass-user 
mailto:grass-user@lists.osgeo.org>>, William 
Kyngesburye mailto:kyngch...@kyngchaos.com>>, Anna 
Petrášová mailto:kratocha...@gmail.com>>
Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)

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).

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=CwMGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=N34HRpJ-bC99jAGZ6tcCUmsLYWp4ag3ao63cVcQxtas&s=OOfq3SrregbqJyJJsSRq_KnX6v97McV_ZatMot9KoUo&e=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=CwMGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=N34HRpJ-bC99jAGZ6tcCUmsLYWp4ag3ao63cVcQxtas&s=aW2Qzkj3CbpJ_WG702f-HFbsFcbHaDAMFuOnfIPKnto&e=>















On Mar 15, 2016, at 3:14 PM, Carlos Grohmann 
mailto:carlos.grohm...@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 
mailto:adershow...@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<https://urldefense.proofpoint.com/v2/url?u=https-3A__support.apple.com_en-2Dus_HT204899&d=CwMGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=N34HRpJ-bC99jAGZ6tcCUmsLYWp4ag3ao63cVcQxtas&s=a-oC6gCKpo7blZOUSNUaANduhi07GUVwoFKvZ6jYnoI&e=>
 )
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<https://urldefense.proofpoint.com/v2/url?u=http-3A__carlosgrohmann.com_&d=CwMGaQ&c=t0wRGL5ICVzH157W8C8

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

[Rainer M Krug]

Michael Barton  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
>  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
>  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/-0001-5073-5572
> 
> 
> Can’t stop the signal.
>
>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Michael Barton]

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).

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 
mailto:carlos.grohm...@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 
mailto:adershow...@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/-0001-5073-5572

Can’t stop the signal.

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

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

[Rainer M Krug]

Carlos Grohmann  writes:

> 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.

Absolutely.

>
> I don't understand why GRASS is offending SIP. Perhaps we should seek
> out for help from others. Maybe Apple itself. 

There were some explanations from Michael why this happens on this
list and also possible solutions - I'll see if I can find them...

Here:

,
| Subject: Re: [GRASS-dev] GRASS on OS X El Capitan - slowly dying or is 
something happening?
| To: GRASS developers list 
| Cc: Rainer M Krug , William Kyngesburye 
, Anna Petrášová , Brian Miles 

| Date: Thu, 21 Jan 2016 19:19:10 +
| 
| AFAICT, the binaries I am compiling under Mavericks work with El Capitan IF 
you turn off System Integrity Protection (to get to the same level of security 
available in
| Mavericks).
| 
| I have not yet updated to El Capitan because I'm hoping someone can tell me 
if they can compile GRASS with it. I don't want to get to situation where I 
can't produce binaries
| for the community. But I would like to upgrade pretty soon.
| 
| There are several things in process right now. William, Brian Miles, and I 
have talked about how to deal with the SIP problem. William has an idea of why 
it is a problem.
| Fixing it will require significant change for how dependencies are packaged 
and referenced. This related to the second thing.
| 
| We've had to compile GRASS with dual 32 bit/64 bit architecture for several 
years because v. 2.8.x of wxPython is 32 bit and subsequent versions of 
wxPython did not work well
| or did not work with GRASS. We've started trying again to get GRASS working 
with 64 bit wxPython 3 and are having some success. (If anyone wants to test a 
version, please let
| me know and I'll provide a link to a binary). Because we have to package 
wxPython with GRASS, and the 32/64 bit dual architecture compilation is causing 
increasing problems,
| we need to solve that.
| 
| If we can get these things worked out, I hope someone can try to compile 
GRASS with El Capitan and stock Mac Python, etc. to make sure it all works.
`

Also the Thread "GRASS on OS X El Capitan - slowly dying or is something 
happening?"


>
> 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?

Using /usr/local is also tricky as it needs to be created without SIP -
but afterwards, SIP can be enabled again. (see

http://digitizor.com/install-homebrew-osx-el-capitan/

)

I actually think that if homebrew is easiewr to make to work, than this
should be the first step.

Cheers,

Rainer

>
> best
>
> Carlos
>
> On Tue, Mar 15, 2016 at 9:51 AM, Adam Dershowitz
>  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

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Carlos Grohmann]

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 
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/-0001-5073-5572

Can’t stop the signal.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Rainer M Krug]

Adam Dershowitz  writes:

> 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).

If I remember correctly, one reason is the use of DYN_LIB path in
GRASS. 

The reason is not the writing into these protected directories. I
managed to compile and run grass 7.1 dev (including GUI) using homebrew, but it 
required
many steps of ignoring errors, make, make install, make, make install as
the directories where the compiled libraries are found were somehow not
available during the compilation process. And the source directory as
well as the compiled and installed files are needed for running GRASS. 

So I would say it is more a structural problem (how GRASS is compiled, 
installed,
how paths to libraries are passed, ...) and not a problem of GRASS not
running on El Capitan.

Cheers,

Rainer


>
>
> -- Adam
>
>
>
>
>
>
> On 3/15/16, 5:20 AM, "Michael Barton"  wrote:
>
>>After this problem was discovered 4-6 months ago, we've been working on a
>>way to remedy it. We have a basic plan that William has suggested, but it
>>takes some time to work out how to implement it. So far, no one has had
>>the time needed to do this. It seems solvable with some effort.
>>
>>
>>
>>My understanding is that SIP is a new security feature. Disabling it
>>leaves the Mac at the same level of security it has under Yosemite.
>>
>>
>>
>>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=Du-iDnFBgCWnlt2qQbjsC_YSg06yHml6QRl_8z3v6Ks&s=BMSNf4uJ_w2
>>ewwUgMTyEGQGU5wecIjrAaBpBY-3ebyA&e= ,
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=CwIGaQ&;
>>c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=D
>>u-iDnFBgCWnlt2qQbjsC_YSg06yHml6QRl_8z3v6Ks&s=nYM20vxBK7g_tQPNjML5LWX-szqTa
>>83D4p5P1fuat1o&e= 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Mar 15, 2016, at 11:00 AM, Rainer M Krug  wrote:
>>
>>> 
>>
>>> Adam Dershowitz  writes:
>>
>>> 
>>
>>>> So it looks like this is actually the known problem with System
>>
>>>> Integrity Protection. I hate to turn off a security feature, and do
>>
>>>> two reboots, to be able to run a single application. Has there been
>>
>>>> any progress in getting this fixed?
>>
>>> 
>>
>>> No - I have the feeling that the ones using GRASS on OS X are still
>>
>>> avoiding upgrading to El Capitan, and the ones who have are out in the
>>
>>> cold. I raised the issue several times already.
>>
>>> 
>>
>>> I slowly really think the best would be to abandon GRASS on OS X and
>>
>>> focus on setting up an official docker image which can be used on OS X,
>>
>>> Windows and Linux.
>>
>>> 
>>
>>> Please convince me otherwise.
>>
>>> 
>>
>>> Cheers,
>>
>>> 
>>
>>> Rainer
>>
>>> 
>>
>>>> 
>>
>>>> Thanks,
>>
>>>> 
>>
>>>> -- Adam
>>
>>>> 
>>
>>>> From: Adam Dershowitz 
>>
>>>> Date: Monday, March 14

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

[Adam Dershowitz]

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






On 3/15/16, 5:20 AM, "Michael Barton"  wrote:

>After this problem was discovered 4-6 months ago, we've been working on a
>way to remedy it. We have a basic plan that William has suggested, but it
>takes some time to work out how to implement it. So far, no one has had
>the time needed to do this. It seems solvable with some effort.
>
>
>
>My understanding is that SIP is a new security feature. Disabling it
>leaves the Mac at the same level of security it has under Yosemite.
>
>
>
>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=Du-iDnFBgCWnlt2qQbjsC_YSg06yHml6QRl_8z3v6Ks&s=BMSNf4uJ_w2
>ewwUgMTyEGQGU5wecIjrAaBpBY-3ebyA&e= ,
>https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=CwIGaQ&;
>c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=D
>u-iDnFBgCWnlt2qQbjsC_YSg06yHml6QRl_8z3v6Ks&s=nYM20vxBK7g_tQPNjML5LWX-szqTa
>83D4p5P1fuat1o&e= 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> On Mar 15, 2016, at 11:00 AM, Rainer M Krug  wrote:
>
>> 
>
>> Adam Dershowitz  writes:
>
>> 
>
>>> So it looks like this is actually the known problem with System
>
>>> Integrity Protection. I hate to turn off a security feature, and do
>
>>> two reboots, to be able to run a single application. Has there been
>
>>> any progress in getting this fixed?
>
>> 
>
>> No - I have the feeling that the ones using GRASS on OS X are still
>
>> avoiding upgrading to El Capitan, and the ones who have are out in the
>
>> cold. I raised the issue several times already.
>
>> 
>
>> I slowly really think the best would be to abandon GRASS on OS X and
>
>> focus on setting up an official docker image which can be used on OS X,
>
>> Windows and Linux.
>
>> 
>
>> Please convince me otherwise.
>
>> 
>
>> Cheers,
>
>> 
>
>> Rainer
>
>> 
>
>>> 
>
>>> Thanks,
>
>>> 
>
>>> -- Adam
>
>>> 
>
>>> From: Adam Dershowitz 
>
>>> Date: Monday, March 14, 2016 at 11:21 PM
>
>>> To: Michael Barton , grass-user grass-user
>
>>> 
>
>>> Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>
>>> wxPython (missing)
>
>>> 
>
>>> And, I just tried to run 6.4, which I still had installed, and it also
>
>>> won¹t run, but with a different error:
>
>>> 
>
>>> Python 2.7.10 found.
>
>>> 
>
>>> Cleaning up temporary files ...
>
>>> 
>
>>> Starting GRASS ...
>
>>> 
>
>>> Traceback (most recent call last):
>
>>> 
>
>>> File
>
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py",
>
>>> line 37, in 
>
>>> 
>
>>> from core import globalvar
>
>>> 
>
>>> File
>
>>> 
>>>"/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.
>>>py",
>
>>> line 74, in 
>
>>> 
>
>>> import wx
>
>>> 
>
>>> File
>
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py",
>
>>> line 45, in 
>
>>> 
>
>>> from wx._core import *
&

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

[Rainer M Krug]

Ken Mankoff  writes:

> On 2016-03-15 at 08:45, Adam Dershowitz  wrote:
>> If people are avoiding a useful system upgrade because of a single
>> application, that indicates that the application is important.
>
> Agreed.
>
>> I've never used docker, but was just checking up on, and it doesn¹t
>> appear to be free, nor does it appear to work on Macs.
>
> I don't think Docker is the solution. It does work on OS X, but not
> "natively". And it is non-trivial for a newbie and a much higher
> barrier of entry than a classic VM (VirtualBox).

Slightly more complex - but a VM runs slower, needs more resources (if I
am not mistaken) and much more hdd space.

>
>> I believe the one of the reasons for the shift to wxpython, years ago,
>> was to keep cross platform support.
>
> Wouldn't a CLI-only port for OS X be an option, or a starting place, if the 
> GUI is the problem?

Absolutely - that would be already a very good start.

>
>   -k.

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Rainer M Krug]

Adam Dershowitz  writes:

> If people are avoiding a useful system upgrade because of a single
> application, that indicates that the application is important.
> One of the great things about GRASS is that it runs cross platform.  It
> would be a big shame to give that up.  I hope that the project can move
> forward to keep Mac OS support.

I definitely hope so. It is just that among the developers, not many are
using OS X (I am not a developer)!

It is interesting, that GRASS is the only program I know / use, which
does not run under El Capitan. Most of the others had hick ups, but the
problems were solved (XTraFinder is an exception) eventually, and none
requires disabling of SIP.

I don't really understand where the problem with SIP comes in (except of
the DYN_LIB variable?), as what GRASS is doing, nowhere interferes with
the system (XTraFinder uses code Injection to change the behaviour of
the Finder - so that is different).  

> I¹ve never used docker, but was just checking up on, and it doesn¹t appear
> to be free, nor does it appear to work on Macs.  I could be wrong about
> either, but GRASS runs natively so well, that there really should not be a
> need to give that up.

See https://www.docker.com/ - docker is open source and it runs on Mac
https://docs.docker.com/engine/installation/mac/ .

But I completely agree that GRASS should stay multi-platform - but I
guess something in the compilation / packaging / running structure has
to change for this.

Cheers,

Rainer

> I believe the one of the reasons for the shift to
> wxpython, years ago, was to keep cross platform support.
>
> -- Adam
>
>
>
>
>
>
> On 3/15/16, 5:00 AM, "Rainer M Krug"  wrote:
>
>>Adam Dershowitz  writes:
>>
>>> So it looks like this is actually the known problem with System
>>> Integrity Protection. I hate to turn off a security feature, and do
>>> two reboots, to be able to run a single application. Has there been
>>> any progress in getting this fixed?
>>
>>No - I have the feeling that the ones using GRASS on OS X are still
>>avoiding upgrading to El Capitan, and the ones who have are out in the
>>cold. I raised the issue several times already.
>>
>>I slowly really think the best would be to abandon GRASS on OS X and
>>focus on setting up an official docker image which can be used on OS X,
>>Windows and Linux.
>>
>>Please convince me otherwise.
>>
>>Cheers,
>>
>>Rainer
>>
>>>
>>> Thanks,
>>>
>>> -- Adam
>>>
>>> From: Adam Dershowitz 
>>> Date: Monday, March 14, 2016 at 11:21 PM
>>> To: Michael Barton , grass-user grass-user
>>> 
>>> Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>>> wxPython (missing)
>>>
>>> And, I just tried to run 6.4, which I still had installed, and it also
>>> won¹t run, but with a different error:
>>>
>>> Python 2.7.10 found.
>>>
>>> Cleaning up temporary files ...
>>>
>>> Starting GRASS ...
>>>
>>> Traceback (most recent call last):
>>>
>>> File
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py",
>>> line 37, in 
>>>
>>> from core import globalvar
>>>
>>> File
>>> 
>>>"/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.p
>>>y",
>>> line 74, in 
>>>
>>> import wx
>>>
>>> File
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py",
>>> line 45, in 
>>>
>>> from wx._core import *
>>>
>>> File
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py",
>>> line 4, in 
>>>
>>> import _core_
>>>
>>> ImportError: dlopen
>>> (/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so,
>>> 2): Library not loaded:
>>> /Users/Shared/unix/wxpython-cocoa-lion/lib/libwx_osx_cocoau-3.0.dylib
>>>
>>> Referenced from:
>>> /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so
>>>
>>> Reason: image not found
>>>
>>> Error in GUI startup. If necessary, please
>>>
>>> report this error to the GRASS developers.
>>>
>>> Switching to text mode now.
>>>
>>> Hit RETURN to continue...
>>>
>>> Has anyone had any luck running GRASS on 10.11 at all?
>>>
>>> -- Adam
>>>
>>> From: grass-user  on behalf of
>>> Michael Ba

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

[Ken Mankoff]

On 2016-03-15 at 08:45, Adam Dershowitz  wrote:
> If people are avoiding a useful system upgrade because of a single
> application, that indicates that the application is important.

Agreed.

> I've never used docker, but was just checking up on, and it doesn¹t
> appear to be free, nor does it appear to work on Macs.

I don't think Docker is the solution. It does work on OS X, but not "natively". 
And it is non-trivial for a newbie and a much higher barrier of entry than a 
classic VM (VirtualBox).

> I believe the one of the reasons for the shift to wxpython, years ago,
> was to keep cross platform support.

Wouldn't a CLI-only port for OS X be an option, or a starting place, if the GUI 
is the problem?

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

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

[Adam Dershowitz]

If people are avoiding a useful system upgrade because of a single
application, that indicates that the application is important.
One of the great things about GRASS is that it runs cross platform.  It
would be a big shame to give that up.  I hope that the project can move
forward to keep Mac OS support.
I¹ve never used docker, but was just checking up on, and it doesn¹t appear
to be free, nor does it appear to work on Macs.  I could be wrong about
either, but GRASS runs natively so well, that there really should not be a
need to give that up.  I believe the one of the reasons for the shift to
wxpython, years ago, was to keep cross platform support.

-- Adam






On 3/15/16, 5:00 AM, "Rainer M Krug"  wrote:

>Adam Dershowitz  writes:
>
>> So it looks like this is actually the known problem with System
>> Integrity Protection. I hate to turn off a security feature, and do
>> two reboots, to be able to run a single application. Has there been
>> any progress in getting this fixed?
>
>No - I have the feeling that the ones using GRASS on OS X are still
>avoiding upgrading to El Capitan, and the ones who have are out in the
>cold. I raised the issue several times already.
>
>I slowly really think the best would be to abandon GRASS on OS X and
>focus on setting up an official docker image which can be used on OS X,
>Windows and Linux.
>
>Please convince me otherwise.
>
>Cheers,
>
>Rainer
>
>>
>> Thanks,
>>
>> -- Adam
>>
>> From: Adam Dershowitz 
>> Date: Monday, March 14, 2016 at 11:21 PM
>> To: Michael Barton , grass-user grass-user
>> 
>> Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>> wxPython (missing)
>>
>> And, I just tried to run 6.4, which I still had installed, and it also
>> won¹t run, but with a different error:
>>
>> Python 2.7.10 found.
>>
>> Cleaning up temporary files ...
>>
>> Starting GRASS ...
>>
>> Traceback (most recent call last):
>>
>> File
>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py",
>> line 37, in 
>>
>> from core import globalvar
>>
>> File
>> 
>>"/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.p
>>y",
>> line 74, in 
>>
>> import wx
>>
>> File
>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py",
>> line 45, in 
>>
>> from wx._core import *
>>
>> File
>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py",
>> line 4, in 
>>
>> import _core_
>>
>> ImportError: dlopen
>> (/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so,
>> 2): Library not loaded:
>> /Users/Shared/unix/wxpython-cocoa-lion/lib/libwx_osx_cocoau-3.0.dylib
>>
>> Referenced from:
>> /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so
>>
>> Reason: image not found
>>
>> Error in GUI startup. If necessary, please
>>
>> report this error to the GRASS developers.
>>
>> Switching to text mode now.
>>
>> Hit RETURN to continue...
>>
>> Has anyone had any luck running GRASS on 10.11 at all?
>>
>> -- Adam
>>
>> From: grass-user  on behalf of
>> Michael Barton 
>> Date: Monday, February 15, 2016 at 3:24 PM
>> To: grass-user grass-user 
>> Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>> wxPython (missing)
>>
>> The packaging seems to have gone awry. I've been out of the country
>> and then sick since returning. Once I get well enough to get to the
>> office, I'll try and fix this.
>>
>> 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 Feb 15, 2016, at 12:59 PM, grass-user-requ...@lists.osgeo.org
>> wrote:
>>
>> 
>> 
>> From: gene 
>> 
>> Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>> wxPython (missing)
>> 
>> Date: February 15, 2016 at 11:55:37 AM MST
>> 
>> To: 
>> 
>>
>> 
>> With the 7.0.3 vers

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

[Rainer M Krug]

Michael Barton  writes:

> After this problem was discovered 4-6 months ago, we've been working
> on a way to remedy it. We have a basic plan that William has
> suggested, but it takes some time to work out how to implement it. So
> far, no one has had the time needed to do this. It seems solvable with
> some effort.

That is good news - would this be applicable for homebrew installation
as well, or only for the Frameworks?

Could this be a GSoC project, to make GRASS work under El Capitan
(Framework and homebrew installations)?

>
> My understanding is that SIP is a new security feature. Disabling it
> leaves the Mac at the same level of security it has under Yosemite.

This is true - but SIP is likely to stay, and I think it is not a good
idea to disable it, as it might be not possible to disable it in the
future.

Thanks,

Rainer

>
> 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 11:00 AM, Rainer M Krug  wrote:
>> 
>> Adam Dershowitz  writes:
>> 
>>> So it looks like this is actually the known problem with System
>>> Integrity Protection. I hate to turn off a security feature, and do
>>> two reboots, to be able to run a single application. Has there been
>>> any progress in getting this fixed?
>> 
>> No - I have the feeling that the ones using GRASS on OS X are still
>> avoiding upgrading to El Capitan, and the ones who have are out in the
>> cold. I raised the issue several times already.
>> 
>> I slowly really think the best would be to abandon GRASS on OS X and
>> focus on setting up an official docker image which can be used on OS X,
>> Windows and Linux.
>> 
>> Please convince me otherwise. 
>> 
>> Cheers,
>> 
>> Rainer
>> 
>>> 
>>> Thanks,
>>> 
>>> -- Adam
>>> 
>>> From: Adam Dershowitz 
>>> Date: Monday, March 14, 2016 at 11:21 PM
>>> To: Michael Barton , grass-user grass-user
>>> 
>>> Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>>> wxPython (missing)
>>> 
>>> And, I just tried to run 6.4, which I still had installed, and it also
>>> won’t run, but with a different error:
>>> 
>>> Python 2.7.10 found.
>>> 
>>> Cleaning up temporary files ...
>>> 
>>> Starting GRASS ...
>>> 
>>> Traceback (most recent call last):
>>> 
>>> File
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py",
>>> line 37, in 
>>> 
>>> from core import globalvar
>>> 
>>> File
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.py",
>>> line 74, in 
>>> 
>>> import wx
>>> 
>>> File
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py",
>>> line 45, in 
>>> 
>>> from wx._core import *
>>> 
>>> File
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py",
>>> line 4, in 
>>> 
>>> import _core_
>>> 
>>> ImportError: dlopen
>>> (/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so,
>>> 2): Library not loaded:
>>> /Users/Shared/unix/wxpython-cocoa-lion/lib/libwx_osx_cocoau-3.0.dylib
>>> 
>>> Referenced from:
>>> /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so
>>> 
>>> Reason: image not found
>>> 
>>> Error in GUI startup. If necessary, please
>>> 
>>> report this error to the GRASS developers.
>>> 
>>> Switching to text mode now.
>>> 
>>> Hit RETURN to continue...
>>> 
>>> Has anyone had any luck running GRASS on 10.11 at all? 
>>> 
>>> -- Adam
>>> 
>>> From: grass-user  on behalf of
>>> Michael Barton 
>>> Date: Monday, February 15, 2016 at 3:24 PM
>>> To: grass-user grass-user 
>>> Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>>> wxPython (missing)
>>> 
>>>

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

[Michael Barton]

After this problem was discovered 4-6 months ago, we've been working on a way 
to remedy it. We have a basic plan that William has suggested, but it takes 
some time to work out how to implement it. So far, no one has had the time 
needed to do this. It seems solvable with some effort. 

My understanding is that SIP is a new security feature. Disabling it leaves the 
Mac at the same level of security it has under Yosemite.

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 11:00 AM, Rainer M Krug  wrote:
> 
> Adam Dershowitz  writes:
> 
>> So it looks like this is actually the known problem with System
>> Integrity Protection. I hate to turn off a security feature, and do
>> two reboots, to be able to run a single application. Has there been
>> any progress in getting this fixed?
> 
> No - I have the feeling that the ones using GRASS on OS X are still
> avoiding upgrading to El Capitan, and the ones who have are out in the
> cold. I raised the issue several times already.
> 
> I slowly really think the best would be to abandon GRASS on OS X and
> focus on setting up an official docker image which can be used on OS X,
> Windows and Linux.
> 
> Please convince me otherwise. 
> 
> Cheers,
> 
> Rainer
> 
>> 
>> Thanks,
>> 
>> -- Adam
>> 
>> From: Adam Dershowitz 
>> Date: Monday, March 14, 2016 at 11:21 PM
>> To: Michael Barton , grass-user grass-user
>> 
>> Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>> wxPython (missing)
>> 
>> And, I just tried to run 6.4, which I still had installed, and it also
>> won’t run, but with a different error:
>> 
>> Python 2.7.10 found.
>> 
>> Cleaning up temporary files ...
>> 
>> Starting GRASS ...
>> 
>> Traceback (most recent call last):
>> 
>> File
>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py",
>> line 37, in 
>> 
>> from core import globalvar
>> 
>> File
>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.py",
>> line 74, in 
>> 
>> import wx
>> 
>> File
>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py",
>> line 45, in 
>> 
>> from wx._core import *
>> 
>> File
>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py",
>> line 4, in 
>> 
>> import _core_
>> 
>> ImportError: dlopen
>> (/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so,
>> 2): Library not loaded:
>> /Users/Shared/unix/wxpython-cocoa-lion/lib/libwx_osx_cocoau-3.0.dylib
>> 
>> Referenced from:
>> /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so
>> 
>> Reason: image not found
>> 
>> Error in GUI startup. If necessary, please
>> 
>> report this error to the GRASS developers.
>> 
>> Switching to text mode now.
>> 
>> Hit RETURN to continue...
>> 
>> Has anyone had any luck running GRASS on 10.11 at all? 
>> 
>> -- Adam
>> 
>> From: grass-user  on behalf of
>> Michael Barton 
>> Date: Monday, February 15, 2016 at 3:24 PM
>> To: grass-user grass-user 
>> Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>> wxPython (missing)
>> 
>> The packaging seems to have gone awry. I've been out of the country
>> and then sick since returning. Once I get well enough to get to the
>> office, I'll try and fix this. 
>> 
>> 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 Feb 15, 2016, at 12:59 PM, grass-user-requ...@lists.osgeo.org
>>wrote:
>> 
>> 
>> 
>>From: gene 
>> 
>>Subject: [GRASS-user] GRASS GIS 7.03 for Mac 

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

[Rainer M Krug]

Adam Dershowitz  writes:

> So it looks like this is actually the known problem with System
> Integrity Protection. I hate to turn off a security feature, and do
> two reboots, to be able to run a single application. Has there been
> any progress in getting this fixed?

No - I have the feeling that the ones using GRASS on OS X are still
avoiding upgrading to El Capitan, and the ones who have are out in the
cold. I raised the issue several times already.

I slowly really think the best would be to abandon GRASS on OS X and
focus on setting up an official docker image which can be used on OS X,
Windows and Linux.

Please convince me otherwise. 

Cheers,

Rainer

>
> Thanks,
>
> -- Adam
>
> From: Adam Dershowitz 
> Date: Monday, March 14, 2016 at 11:21 PM
> To: Michael Barton , grass-user grass-user
> 
> Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
> wxPython (missing)
>
> And, I just tried to run 6.4, which I still had installed, and it also
> won’t run, but with a different error:
>
> Python 2.7.10 found.
>
> Cleaning up temporary files ...
>
> Starting GRASS ...
>
> Traceback (most recent call last):
>
> File
> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py",
> line 37, in 
>
> from core import globalvar
>
> File
> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.py",
> line 74, in 
>
> import wx
>
> File
> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py",
> line 45, in 
>
> from wx._core import *
>
> File
> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py",
> line 4, in 
>
> import _core_
>
> ImportError: dlopen
> (/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so,
> 2): Library not loaded:
> /Users/Shared/unix/wxpython-cocoa-lion/lib/libwx_osx_cocoau-3.0.dylib
>
> Referenced from:
> /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so
>
> Reason: image not found
>
> Error in GUI startup. If necessary, please
>
> report this error to the GRASS developers.
>
> Switching to text mode now.
>
> Hit RETURN to continue...
>
> Has anyone had any luck running GRASS on 10.11 at all? 
>
> -- Adam
>
> From: grass-user  on behalf of
> Michael Barton 
> Date: Monday, February 15, 2016 at 3:24 PM
> To: grass-user grass-user 
> Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
> wxPython (missing)
>
> The packaging seems to have gone awry. I've been out of the country
> and then sick since returning. Once I get well enough to get to the
> office, I'll try and fix this. 
>
> 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 Feb 15, 2016, at 12:59 PM, grass-user-requ...@lists.osgeo.org
> wrote:
>
> 
> 
> From: gene 
> 
> Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
> wxPython (missing)
> 
> Date: February 15, 2016 at 11:55:37 AM MST
> 
> To: 
> 
>
> 
> With the 7.0.3 version of GRASS GIS on the Mac (M.Barton)
> <http://grassmac.wikidot.com/> I can only launch GRASS-7.0.app
> (7.0.3) in
> text mode.
> 
> When I try to launch the App or use g.gui wxpython in the Grass
> shell the
> error is:
> 
> "Launching  GUI in the background, please wait…
> ERROR: wxGUI requires wxPython. No module named wxversion
> 
> In the 7.0.2 version, wxPython is installed in
> /Applications/GRASS-7.0.app/Contents/MacOS/etc/python (wx,
> wxpython and
> pyparsing.py and wxversion.py) and it works.
> 
> But none of these files/folders exist in the same folder of the
> 7.0.3
> version 
> 
> Compilation error ?
> 
> The size of the zip files are also different (80.19 and 83.89 for
> GRASS 7.01
> and GRASS 7.02, 35 .12 for GRASS 7.03)
> 
> Many thanks
> 
> 
> 
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Adam Dershowitz]

So it looks like this is actually the known problem with System Integrity 
Protection.  I hate to turn off a security feature, and do two reboots,  to be 
able to run a  single application.  Has there been any progress in getting this 
fixed?

Thanks,

-- Adam


From: Adam Dershowitz 
mailto:adershow...@exponent.com>>
Date: Monday, March 14, 2016 at 11:21 PM
To: Michael Barton mailto:michael.bar...@asu.edu>>, 
grass-user grass-user 
mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)

And, I just tried to run 6.4, which I still had installed, and it also won’t 
run, but with a different error:


Python 2.7.10 found.

Cleaning up temporary files ...

Starting GRASS ...

Traceback (most recent call last):

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py", 
line 37, in 

from core import globalvar

  File 
"/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.py", 
line 74, in 

import wx

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: 
/Users/Shared/unix/wxpython-cocoa-lion/lib/libwx_osx_cocoau-3.0.dylib

  Referenced from: 
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

Error in GUI startup. If necessary, please

report this error to the GRASS developers.

Switching to text mode now.

Hit RETURN to continue...




Has anyone had any luck running GRASS on 10.11 at all?


-- Adam


From: grass-user 
mailto:grass-user-boun...@lists.osgeo.org>> 
on behalf of Michael Barton 
mailto:michael.bar...@asu.edu>>
Date: Monday, February 15, 2016 at 3:24 PM
To: grass-user grass-user 
mailto:grass-user@lists.osgeo.org>>
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)

The packaging seems to have gone awry. I've been out of the country and then 
sick since returning. Once I get well enough to get to the office, I'll try and 
fix this.

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=CwMGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=mQkXH1ueNkuN6x_ULoNTVKf8HhzY3BksHkBifuT4ei4&s=hiCFoOIof6xOrTVN-DtaoSCJKiGlG1cbfpgCAh75ATw&e=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=CwMGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=mQkXH1ueNkuN6x_ULoNTVKf8HhzY3BksHkBifuT4ei4&s=LUWEhxCbJLRMSGP1xOrwKsANc9PwKuLL8M8DAqgRa3c&e=>




On Feb 15, 2016, at 12:59 PM, 
grass-user-requ...@lists.osgeo.org<mailto:grass-user-requ...@lists.osgeo.org> 
wrote:

From: gene mailto:martin.lal...@gmail.com>>
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)
Date: February 15, 2016 at 11:55:37 AM MST
To: mailto:grass-user@lists.osgeo.org>>


With the 7.0.3 version of  GRASS GIS on the Mac (M.Barton)
<http://grassmac.wikidot.com/<https://urldefense.proofpoint.com/v2/url?u=http-3A__grassmac.wikidot.com_&d=CwMGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=mQkXH1ueNkuN6x_ULoNTVKf8HhzY3BksHkBifuT4ei4&s=noVWFNeapzu4k_YxtrbHFY7wpnxZuLJcx6PEmEIKXrM&e=>>
   I can only launch GRASS-7.0.app (7.0.3) in
text mode.

When I try to launch the App or use g.gui wxpython in the Grass shell the
error is:

"Launching  GUI in the background, please wait…
ERROR: wxGUI requires wxPython. No module named wxversion

In the 7.0.2 version, wxPython is installed in
/Applications/GRASS-7.0.app/Contents/MacOS/etc/python (wx, wxpython and
pyparsing.py and wxversion.py) and it works.

But none of these files/folders exist in the same folder of the 7.0.3
version

Compilation error ?

The size of the zip files are also different (80.19 and 83.89 for GRASS 7.01
and GRASS 7.02, 35 .12 for GRASS 7.03)

Many thanks



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

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

[Adam Dershowitz]

Any luck with this?
I just tried to use 7.0.2 and when it failed, I download and tried 7.0.3, which 
also failed.

When I try to run it, I see this:


Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

dyld: Library not loaded: /usr/local/lib/libintl.8.dylib

  Referenced from: 
/Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.3.dylib

  Reason: image not found


And, then as a work around I tried to use the Macports version of that file 
like this:

install_name_tool -change /usr/local/lib/libintl.8.dylib 
/opt/local/lib/libintl.8.dylib 
/Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.3.dylib


but instead I now get this error:

adershowitzMBP15:~ adershowitz$ 
'/Applications/GRASS-7.0.app/Contents/MacOS/grass.sh'; exit

Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

Traceback (most recent call last):

  File "/Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 84, in 

import wx

  File "/Applications/GRASS-7.0.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: 
/usr/local/lib/wxPython-unicode-2.8.12.1/lib/libwx_macud-2.8.0.dylib

  Referenced from: 
/Applications/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

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

Switching to text mode now.

Any suggestions or work around would be greatly appreciated.  I have some data 
that I need access to, and usually GRASS is solid and reliable, so not being 
able to use it is worrisome.

Thanks,


-- Adam


From: grass-user 
mailto:grass-user-boun...@lists.osgeo.org>> 
on behalf of Michael Barton 
mailto:michael.bar...@asu.edu>>
Date: Monday, February 15, 2016 at 3:24 PM
To: grass-user grass-user 
mailto:grass-user@lists.osgeo.org>>
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)

The packaging seems to have gone awry. I've been out of the country and then 
sick since returning. Once I get well enough to get to the office, I'll try and 
fix this.

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 Feb 15, 2016, at 12:59 PM, 
grass-user-requ...@lists.osgeo.org 
wrote:

From: gene mailto:martin.lal...@gmail.com>>
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)
Date: February 15, 2016 at 11:55:37 AM MST
To: mailto:grass-user@lists.osgeo.org>>


With the 7.0.3 version of  GRASS GIS on the Mac (M.Barton)
>
   I can only launch GRASS-7.0.app (7.0.3) in
text mode.

When I try to launch the App or use g.gui wxpython in the Grass shell the
error is:

"Launching  GUI in the background, please wait…
ERROR: wxGUI requires wxPython. No module named wxversion

In the 7.0.2 version, wxPython is installed in
/Applications/GRASS-7.0.app/Contents/MacOS/etc/python (wx, wxpython and
pyparsing.py and wxversion.py) and it works.

But none of these files/folders exist in the same folder of the 7.0.3
version

Compilation error ?

The size of the zip files are also different (80.19 and 83.89 for GRASS 7.01
and GRASS 7.02, 35 .12 for GRASS 7.03)

Many thanks



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

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

[Adam Dershowitz]

And, I just tried to run 6.4, which I still had installed, and it also won’t 
run, but with a different error:


Python 2.7.10 found.

Cleaning up temporary files ...

Starting GRASS ...

Traceback (most recent call last):

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py", 
line 37, in 

from core import globalvar

  File 
"/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.py", 
line 74, in 

import wx

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: 
/Users/Shared/unix/wxpython-cocoa-lion/lib/libwx_osx_cocoau-3.0.dylib

  Referenced from: 
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

Error in GUI startup. If necessary, please

report this error to the GRASS developers.

Switching to text mode now.

Hit RETURN to continue...




Has anyone had any luck running GRASS on 10.11 at all?


-- Adam


From: grass-user 
mailto:grass-user-boun...@lists.osgeo.org>> 
on behalf of Michael Barton 
mailto:michael.bar...@asu.edu>>
Date: Monday, February 15, 2016 at 3:24 PM
To: grass-user grass-user 
mailto:grass-user@lists.osgeo.org>>
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)

The packaging seems to have gone awry. I've been out of the country and then 
sick since returning. Once I get well enough to get to the office, I'll try and 
fix this.

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 Feb 15, 2016, at 12:59 PM, 
grass-user-requ...@lists.osgeo.org 
wrote:

From: gene mailto:martin.lal...@gmail.com>>
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)
Date: February 15, 2016 at 11:55:37 AM MST
To: mailto:grass-user@lists.osgeo.org>>


With the 7.0.3 version of  GRASS GIS on the Mac (M.Barton)
>
   I can only launch GRASS-7.0.app (7.0.3) in
text mode.

When I try to launch the App or use g.gui wxpython in the Grass shell the
error is:

"Launching  GUI in the background, please wait…
ERROR: wxGUI requires wxPython. No module named wxversion

In the 7.0.2 version, wxPython is installed in
/Applications/GRASS-7.0.app/Contents/MacOS/etc/python (wx, wxpython and
pyparsing.py and wxversion.py) and it works.

But none of these files/folders exist in the same folder of the 7.0.3
version

Compilation error ?

The size of the zip files are also different (80.19 and 83.89 for GRASS 7.01
and GRASS 7.02, 35 .12 for GRASS 7.03)

Many thanks



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