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

Rainer M Krug Rainer at krugs.de
Thu Mar 17 01:30:57 PDT 2016 

Adam Dershowitz <adershowitz at exponent.com> writes:

> On 3/16/16, 9:03 AM, "Michael Barton" <Michael.Barton at asu.edu> wrote:
>
>>I've held off updating to make sure I could continue to provide binaries
>>for the GRASS community. If you are right, I will upgrade one of my
>>computers to the new OS and try this. SIP off and compile.
>
>
> I hope that will work. But, I did just try to install your binaries
> without SIP, then reenabled and it failed to run.  Hopefully, your rebuild
> will fix it.  

According to Williams email, not (
http://permalink.gmane.org/gmane.comp.gis.grass.user/53067 )

> FYI, I do really appreciate that you provide the binaries!  Thank you.
>
>> 
>>
>>
>>
>>The question then is whether users need to turn SIP off to install in the
>>normal applications folder.
>
>
> No, they don’t.  The vast majority of applications have not had any
> problems transitioning to SIP.  The only exceptions that I have heard of
> having any problems are an application that tries to do some low-level
> finder stuff (so it actually could be considered a real security risk) and
> GRASS.  Although, my sampling is far from complete!

I have exactly the same impression.


>
>
>>
>>
>>
>>Michael
>>
>>____________________
>>
>>C. Michael Barton
>>
>>Director, Center for Social Dynamics & Complexity
>>
>>Professor of Anthropology, School of Human Evolution & Social Change
>>
>>Head, Graduate Faculty in Complex Adaptive Systems Science
>>
>>Arizona State University
>>
>>
>>
>>voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>>
>>fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>>
>>www: 
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7E
>>cmbarton&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28T
>>aiOmWcn6rCn8wM&m=8a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs&s=brH8l8fvJcn
>>BOtKN-Iit46NVfqgp0TIE-1AzhSS-BOs&e= ,
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=CwIGaQ&
>>c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=8
>>a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs&s=4QJPzCYG_0w7Wr4CmDr_AQ1GzmaYY
>>SRUHhN3ywKiNnk&e= 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Mar 16, 2016, at 12:24 PM, Rainer M Krug <Rainer at krugs.de> wrote:
>>
>>> 
>>
>>> Rainer M Krug <Rainer at krugs.de> writes:
>>
>>> 
>>
>>>> Adam Dershowitz <adershowitz at exponent.com> writes:
>>
>>>> 
>>
>>>>> Got it.  Now, based on that, I have found it.  Apparently, it is for
>>
>>>>> protected processes:
>>
>>>>> 
>>
>>>>> 
>>>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.co
>>>>>m_library_mac_documentation_Security_Conceptual_S&d=CwIGaQ&c=t0wRGL5ICV
>>>>>zH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=8a8vJwN3CL
>>>>>QA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs&s=lpyQ9k04zOgM7WEr5IuYKSvzyOXTxIPvKFF
>>>>>p5HLGOCU&e= 
>>
>>>>> 
>>>>>ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.
>>>>>html
>>
>>>>> 
>>
>>>> 
>>
>>>> Which seems to be the reason why during the make step (make is in
>>
>>>> /usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is
>>
>>>> ignored.
>>
>>>> 
>>
>>>> But when running GRASS, it should work.
>>
>>>> 
>>
>>>> Has anybody tried out to
>>
>>>> 
>>
>>>> 1) disable SIP
>>
>>>> 2) compile GRASS from source
>>
>>>> 3) install GRASS
>>
>>>> 4) enable SIP
>>
>>>> 
>>
>>>> and does it run?
>>
>>> 
>>
>>> 
>>
>>> Just tried it out, ant it works. So the DYLD_LIBRARY_PATH issue only
>>
>>> affects the compilation / installation of GRASS.
>>
>>> 
>>
>>> 
>>
>>>> 
>>
>>>> Do you know if Macports uses an own make (and possibly other tools?),
>>>>or
>>
>>>> the one supplied by OS X?
>>
>>>> 
>>
>>>> 
>>
>>>>> So, would it be possible to just just the paths that are used for the
>>
>>>>> search paths in the Application bundle itself?
>>
>>>>> 
>>
>>>>> -- Adam
>>
>>>>> 
>>
>>>>> 
>>
>>>>> 
>>
>>>>> 
>>
>>>>> 
>>
>>>>> 
>>
>>>>> On 3/15/16, 4:43 PM, "William Kyngesburye" <woklist at kyngchaos.com>
>>>>>wrote:
>>
>>>>> 
>>
>>>>>> GRASS does not write to those SIP-restricted locations.
>>
>>>>>> 
>>
>>>>>> From what I've read, SIP also causes apps to ignore
>>>>>>DYLD_LIBRARY_PATH, no
>>
>>>>>> matter where it points to.  And the errors that have been reported
>>>>>>point
>>
>>>>>> to it as well.
>>
>>>>>> 
>>
>>>>>>> On Mar 15, 2016, at 3:06 PM, Adam Dershowitz
>>>>>>><adershowitz at exponent.com>
>>
>>>>>>> wrote:
>>
>>>>>>> 
>>
>>>>>>> 
>>
>>>>>>> 
>>
>>>>>>> 
>>
>>>>>>> 
>>
>>>>>>> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
>>
>>>>>>> <grass-user-bounces at lists.osgeo.org on behalf of
>>>>>>>woklist at kyngchaos.com>
>>
>>>>>>> wrote:
>>
>>>>>>> 
>>
>>>>>>>> On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer at krugs.de> wrote:
>>
>>>>>>>>> 
>>
>>>>>>>>> William Kyngesburye <woklist at kyngchaos.com> writes:
>>
>>>>>>>>> 
>>
>>>>>>>>>> This is also a known issue, related to but separate from the
>>
>>>>>>>>>> packaging
>>
>>>>>>>>>> issue.  During compilation, GRASS also uses DYLD_LIBRARY_PATH to
>>>>>>>>>>find
>>
>>>>>>>>>> the in-compilation copies of the libraries so it can run the
>>>>>>>>>>modules
>>
>>>>>>>>>> to create the help files.
>>
>>>>>>>>> 
>>
>>>>>>>>> OK - this aligns with what I guessed from the error messages.
>>
>>>>>>>>> 
>>
>>>>>>>>> So the  DYLD_LIBRARY_PATH is only used during compilation - and
>>>>>>>>>not
>>
>>>>>>>>> during execution, even without "make install"?
>>
>>>>>>>>> 
>>
>>>>>>>> No, DYLD_LIBRARY_PATH is also used during execution, that's what's
>>
>>>>>>>> causing trouble in the app bundling.
>>
>>>>>>>> 
>>
>>>>>>>>>> 
>>
>>>>>>>>>> The packaging issue with DYLD_LIBRARY_PATH can be fixed in
>>>>>>>>>>packaging
>>
>>>>>>>>>> so that everything within the GRASS app package looks directly
>>>>>>>>>>inside
>>
>>>>>>>>>> the package for libraries and not rely on DYLD_LIBRARY_PATH.
>>
>>>>>>>>>> Homebrew, Macports and /usr/local builds don't need to worry
>>>>>>>>>>about it
>>
>>>>>>>>>> because the extra dependencies that are bundled in the app are
>>
>>>>>>>>>> already
>>
>>>>>>>>>> in their proper place.
>>
>>>>>>>>> 
>>
>>>>>>>>> OK - so in homebrew (I can't speak for Macports) the issue is at
>>>>>>>>>the
>>
>>>>>>>>> moment only the one you discuss below.
>>
>>>>>>>>> 
>>
>>>>>>>>>> 
>>
>>>>>>>>>> The compilation issue needs work to compile all libraries with
>>>>>>>>>>the
>>
>>>>>>>>>> temporary path inside the libraries and modules (this part is
>>>>>>>>>>easy)
>>
>>>>>>>>>> so
>>
>>>>>>>>>> that during compilation help file generation works.
>>
>>>>>>>>> 
>>
>>>>>>>>> OK - so can you give me any suggestions how I can solve this to
>>>>>>>>>make
>>
>>>>>>>>> GRASS at least compile on homebrew?
>>
>>>>>>>>> 
>>
>>>>>>>>> Speaking generally - is this really the right approach to take,
>>>>>>>>>i.e.
>>
>>>>>>>>> use
>>
>>>>>>>>> the generated binaries to generate the help files during
>>>>>>>>>installation?
>>
>>>>>>>>> Wouldn't it be much easier to do this during installation?
>>
>>>>>>>>> 
>>
>>>>>>>> Well, the compilation approach is how it's been done as long as I
>>>>>>>>can
>>
>>>>>>>> remember, it's nothing specific to OS X.  Changing this would be
>>>>>>>>major.
>>
>>>>>>>> 
>>
>>>>>>>>>> And then during installation change all the embedded library
>>>>>>>>>>paths to
>>
>>>>>>>>>> the final destination (this is harder, to figure out the complex
>>
>>>>>>>>>> makefile include system of GRASS to get this operation in the
>>>>>>>>>>right
>>
>>>>>>>>>> place).
>>
>>>>>>>>> 
>>
>>>>>>>>> The paths are in the grass script file? Or in others as well?
>>
>>>>>>>>> 
>>
>>>>>>>> No, the paths are embedded in the libraries and binary executables.
>>
>>>>>>>> 
>>
>>>>>>>>> Wouldn't it make sense to
>>
>>>>>>>>> 
>>
>>>>>>>>> 1) split the generation of the help files from the build step
>>>>>>>>>into a
>>
>>>>>>>>> separate make target
>>
>>>>>>>>> 2) call the make target for help pages as a last step in the
>>>>>>>>>install
>>
>>>>>>>>> step?
>>
>>>>>>>>> 
>>
>>>>>>>>> This might make packaging more difficult, but wouldn't it make the
>>
>>>>>>>>> whole
>>
>>>>>>>>> process clearer?
>>
>>>>>>>>> 
>>
>>>>>>>>>> Homebrew, Macports, /usr/local AND app installs do have a problem
>>
>>>>>>>>>> with
>>
>>>>>>>>>> this.
>>
>>>>>>>>> 
>>
>>>>>>>>> It worked with Yosemite without problems. So this only needs to be
>>
>>>>>>>>> done,
>>
>>>>>>>>> because of the issues you describe above?
>>
>>>>>>>>> 
>>
>>>>>>>> It's specifically an El Capitan+ issue, because of SIP.
>>
>>>>>>> 
>>
>>>>>>> I wonder if you can explain this anymore.  Because, it is not at all
>>
>>>>>>> clear
>>
>>>>>>> to me.  DYLD_LIBRARY_PATH is something that is used all the time and
>>
>>>>>>> works
>>
>>>>>>> fine in El Capitan for most Applications.  The only thing that SIP
>>
>>>>>>> provides, if I understand correctly, is that it is not possible for
>>>>>>>an
>>
>>>>>>> application to write to /System /bin /sbin or /usr (and a few Apple
>>
>>>>>>> specifics in /Applications).  Writing to /usr/local and /usr/lib
>>>>>>>should
>>
>>>>>>> be
>>
>>>>>>> OK.  Just having all the different versions of libraries around, and
>>
>>>>>>> dynamically finding them should work fine.
>>
>>>>>>> So, during run time, why does GRASS attempt to write to /usr (or
>>>>>>>one of
>>
>>>>>>> the other Apple owned folders?  If it is using DYLD_LIBRARY_PATH to
>>>>>>>find
>>
>>>>>>> the necessary libraries from within the GRASS bundle, there should
>>>>>>>be no
>>
>>>>>>> need to write there.
>>
>>>>>>> Is it doing something unusual, such as at startup it tries to copy
>>>>>>>a few
>>
>>>>>>> files from the bundle to /usr so that it doesn¹t have to change
>>
>>>>>>> DYLD_LIBRARY_PATH?  Even if that is the case, just changing those
>>>>>>>paths
>>
>>>>>>> to
>>
>>>>>>> /usr/local would solve the SIP problem.
>>
>>>>>>> 
>>
>>>>>>> If the problem relates to how GRASS finds the correct version of
>>
>>>>>>> libraries, at least as a work around, it should be possible to use
>>
>>>>>>> install_name_tool to point to the correct version of libraries for
>>>>>>>any
>>
>>>>>>> specific build.  This is what I first attempted, but just fixing one
>>
>>>>>>> library didn¹t do the job for me, as it then triggered another
>>>>>>>problem.
>>
>>>>>>> So, I really don¹t understand what it is that GRASS does, at
>>>>>>>runtime,
>>
>>>>>>> that
>>
>>>>>>> SIP objects to.
>>
>>>>>>> 
>>
>>>>>>> 
>>
>>>>>>>> 
>>
>>>>>>>>>> It works for Michael (and me) for the "official" packages
>>>>>>>>>>because we
>>
>>>>>>>>>> compile on older systems that don't have SIP.
>>
>>>>>>>>> 
>>
>>>>>>>>> Thanks for these clarifications.
>>
>>>>>>>>> 
>>
>>>>>>>>> I would very much appreciate if we could see to get the
>>>>>>>>>compilation
>>
>>>>>>>>> and
>>
>>>>>>>>> installation working using homebrew so that there is at least one
>>>>>>>>>way
>>
>>>>>>>>> of
>>
>>>>>>>>> t=running GRASS on El Capitan without having to interfere with the
>>
>>>>>>>>> security settings.
>>
>>>>>>>>> 
>>
>>>>>>>>> Thanks,
>>
>>>>>>>>> 
>>
>>>>>>>>> Rainer
>>
>>>>>>>>> 
>>
>>>>>>>>>> 
>>
>>>>>>>>>>> On Mar 15, 2016, at 11:39 AM, Rainer M Krug <Rainer at krugs.de>
>>>>>>>>>>>wrote:
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> I tried again to install 7.1 head without GUI using homwbrew,
>>>>>>>>>>>and I
>>
>>>>>>>>>>> get
>>
>>>>>>>>>>> the following error:
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> ,----
>>
>>>>>>>>>>> | bash-4.3$ less
>>
>>>>>>>>>>> /Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
>>
>>>>>>>>>>> | bash-4.3$ cd
>>
>>>>>>>>>>> /private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
>>
>>>>>>>>>>> | bash-4.3$ ls
>>
>>>>>>>>>>> | Makefile        d.rast.leg.html d.rast.leg.py
>>
>>>>>>>>>>> | bash-4.3$ make
>>
>>>>>>>>>>> | if [
>>
>>>>>>>>>>> | 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-da
>>>>>>>>>>>rwin
>>
>>>>>>>>>>> 15
>>
>>>>>>>>>>> .3.0/scripts/d.rast.leg"
>>
>>>>>>>>>>> | != "" ] ; then
>>
>>>>>>>>>>> | 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app
>>>>>>>>>>>le-d
>>
>>>>>>>>>>> ar
>>
>>>>>>>>>>> win15.3.0/demolocation/.grassrc71
>>
>>>>>>>>>>> | 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
>>>>>>>>>>>pple
>>
>>>>>>>>>>> -d
>>
>>>>>>>>>>> arwin15.3.0
>>
>>>>>>>>>>> | 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app
>>>>>>>>>>>le-d
>>
>>>>>>>>>>> ar
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x8
>>>>>>>>>>>6_64
>>
>>>>>>>>>>> -a
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar
>>>>>>>>>>>/dis
>>
>>>>>>>>>>> t.
>>
>>>>>>>>>>> x86_64-apple-darwin15.3.0/scripts:$PATH"
>>
>>>>>>>>>>> | 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_
>>>>>>>>>>>64-a
>>
>>>>>>>>>>> pp
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1y
>>>>>>>>>>>bn5a
>>
>>>>>>>>>>> r/
>>
>>>>>>>>>>> dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
>>
>>>>>>>>>>> | 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/di
>>>>>>>>>>>st.x
>>
>>>>>>>>>>> 86
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1y
>>>>>>>>>>>bn5a
>>
>>>>>>>>>>> r/
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-
>>>>>>>>>>>4734
>>
>>>>>>>>>>> 4-
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass
>>>>>>>>>>>-712
>>
>>>>>>>>>>> 01
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/t
>>>>>>>>>>>mp/g
>>
>>>>>>>>>>> ra
>>
>>>>>>>>>>> ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
>>
>>>>>>>>>>> | LC_ALL=C
>>
>>>>>>>>>>> | 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
>>>>>>>>>>>win1
>>
>>>>>>>>>>> 5.
>>
>>>>>>>>>>> 3.0/scripts/d.rast.leg
>>
>>>>>>>>>>> | --html-description < /dev/null | grep -v '</body>\|</html>' >
>>
>>>>>>>>>>> | d.rast.leg.tmp.html ; fi
>>
>>>>>>>>>>> | dyld: Library not loaded:
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.
>>>>>>>>>>>1.sv
>>
>>>>>>>>>>> n.
>>
>>>>>>>>>>> dylib
>>
>>>>>>>>>>> |   Referenced from:
>>
>>>>>>>>>>> | 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
>>>>>>>>>>>win1
>>
>>>>>>>>>>> 5.
>>
>>>>>>>>>>> 3.0/bin/g.parser
>>
>>>>>>>>>>> |   Reason: image not found
>>
>>>>>>>>>>> | make: *** [d.rast.leg.tmp.html] Error 1
>>
>>>>>>>>>>> | rm d.rast.leg.tmp.html
>>
>>>>>>>>>>> | bash-4.3$
>>
>>>>>>>>>>> `----
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> In other words: grass is looking during the compilation for a
>>
>>>>>>>>>>> dynamic
>>
>>>>>>>>>>> library
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>>>>>>>>>>(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7
>>>>>>>>>>>.1.s
>>
>>>>>>>>>>> vn
>>
>>>>>>>>>>> .dylib)
>>
>>>>>>>>>>> which has been created, but will only be there when installing.
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> Also important: this error only occurs when the html manual
>>>>>>>>>>>pages
>>
>>>>>>>>>>> are
>>
>>>>>>>>>>> created!
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> Cheers,
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> Rainer
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>> Rainer M Krug <Rainer at krugs.de> writes:
>>
>>>>>>>>>>> 
>>
>>>>>>>>>>>> Adam Dershowitz <adershowitz at exponent.com> writes:
>>
>>>>>>>>>>>> 
>>
>>>>>>>>>>>>> I use Macports for a  bunch of other things (and Homebrew is
>>
>>>>>>>>>>>>> incompatible
>>
>>>>>>>>>>>>> with Macports)   So, I figured that I would just tried to
>>>>>>>>>>>>>install
>>
>>>>>>>>>>>>> grass7
>>
>>>>>>>>>>>>> using macports.  It does seem to install, but the gui doesn¹t
>>
>>>>>>>>>>>>> work:
>>
>>>>>>>>>>>>> 
>>
>>>>>>>>>>>>> $grass70
>>
>>>>>>>>>>>>> Cleaning up temporary files...
>>
>>>>>>>>>>>>> Starting GRASS GIS...
>>
>>>>>>>>>>>>> ERROR: wxGUI requires wxPython. No module named wxversion
>>
>>>>>>>>>>>>> Error in GUI startup. If necessary, please report this error
>>>>>>>>>>>>>to
>>
>>>>>>>>>>>>> the
>>
>>>>>>>>>>>>> GRASS
>>
>>>>>>>>>>>>> developers.
>>
>>>>>>>>>>>>> Switching to text mode now.
>>
>>>>>>>>>>>>> 
>>
>>>>>>>>>>>> 
>>
>>>>>>>>>>>> I don't use MacPorts - but can you try to install without GUI?
>>
>>>>>>>>>>>> 
>>
>>>>>>>>>>>>> 
>>
>>>>>>>>>>>>> Hit RETURN to continue...
>>
>>>>>>>>>>>>> 
>>
>>>>>>>>>>>>> 
>>
>>>>>>>>>>>>> 
>>
>>>>>>>>>>>>> This is odd, since wxpython is installed.
>>
>>>>>>>>>>>>> But, it seems like this is a different problem.
>>
>>>>>>>>>>>>> 
>>
>>>>>>>> 
>>
>>>>>>>> -----
>>
>>>>>>>> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
>>
>>>>>>>> 
>>
>>>>>>>> 
>>>>>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.co
>>>>>>>>m_&d
>>
>>>>>>>> =C
>>
>>>>>>>> 
>>
>>>>>>>> 
>>>>>>>>wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWc
>>>>>>>>n6rC
>>
>>>>>>>> n8
>>
>>>>>>>> 
>>
>>>>>>>> 
>>>>>>>>wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1
>>>>>>>>h_V7
>>
>>>>>>>> mJ
>>
>>>>>>>> Bf8t6V3mbREBfgUP8u90&e=
>>
>>>>>>>> 
>>
>>>>>>>> "Oh, look, I seem to have fallen down a deep, dark hole.  Now what
>>>>>>>>does
>>
>>>>>>>> that remind me of?  Ah, yes - life."
>>
>>>>>>>> 
>>
>>>>>>>> - Marvin
>>
>>>>>>>> 
>>
>>>>>>>> 
>>
>>>>>>>> _______________________________________________
>>
>>>>>>>> grass-user mailing list
>>
>>>>>>>> grass-user at lists.osgeo.org
>>
>>>>>>>> 
>>
>>>>>>>> 
>>>>>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_
>>>>>>>>mail
>>
>>>>>>>> ma
>>
>>>>>>>> 
>>
>>>>>>>> 
>>>>>>>>n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGq
>>>>>>>>XabR
>>
>>>>>>>> Lt
>>
>>>>>>>> 
>>
>>>>>>>> 
>>>>>>>>SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1
>>>>>>>>bup-
>>
>>>>>>>> rF
>>
>>>>>>>> c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=
>>
>>>>>>> 
>>
>>>>>>> _______________________________________________
>>
>>>>>>> grass-user mailing list
>>
>>>>>>> grass-user at lists.osgeo.org
>>
>>>>>>> 
>>
>>>>>>> 
>>>>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_m
>>>>>>>ailm
>>
>>>>>>> 
>>>>>>>an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGq
>>>>>>>XabR
>>
>>>>>>> 
>>>>>>>LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_
>>>>>>>TOf4
>>
>>>>>>> CZvY&s=dFMvzAURv7ExJqKWuHhJuiWSp1tVxWAQLXdLERfRUcY&e=
>>
>>>>>> 
>>
>>>>>> -----
>>
>>>>>> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
>>
>>>>>> 
>>>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_
>>>>>>&d=C
>>
>>>>>> 
>>>>>>wIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6
>>>>>>rCn8
>>
>>>>>> 
>>>>>>wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwj
>>>>>>Ww1t
>>
>>>>>> 6syI0zj0Ou2szNtTSNWQ&e=
>>
>>>>>> 
>>
>>>>>> "I ache, therefore I am.  Or in my case - I am, therefore I ache."
>>
>>>>>> 
>>
>>>>>> - Marvin
>>
>>>>>> 
>>
>>>>>> 
>>
>>>>> 
>>
>>>>> _______________________________________________
>>
>>>>> grass-user mailing list
>>
>>>>> grass-user at lists.osgeo.org
>>
>>>>> 
>>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mai
>>>>>lman_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGq
>>>>>XabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=8a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa
>>>>>_5GDDVCFJs&s=zeHh0C0suAsouujRlhHjO0snRjDR9Ga2pfaXnh60h0E&e=
>>
>>> 
>>
>>> -- 
>>
>>> Rainer M. Krug
>>
>>> email: Rainer<at>krugs<dot>de
>>
>>> PGP: 0x0F52F982
>>
>>
>>
>
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20160317/db68b053/attachment-0001.sig>

More information about the grass-user mailing list