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

Tue Mar 15 13:06:35 PDT 2016

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-darwin15
>>>>.3.0/scripts/d.rast.leg"
>>>> | != "" ] ; then
>>>> | 
>>>>GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
>>>>win15.3.0/demolocation/.grassrc71
>>>> | 
>>>>GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
>>>>arwin15.3.0
>>>> | 
>>>>PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
>>>>win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
>>>>pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.
>>>>x86_64-apple-darwin15.3.0/scripts:$PATH"
>>>> | 
>>>>PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app
>>>>le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5ar/
>>>>dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
>>>> | 
>>>>DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86
>>>>_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/
>>>>dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-
>>>>1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-71201
>>>>60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/gra
>>>>ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
>>>> | LC_ALL=C
>>>> | 
>>>>/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.
>>>>3.0/scripts/d.rast.leg
>>>> | --html-description < /dev/null | grep -v '</body>\|</html>' >
>>>> | d.rast.leg.tmp.html ; fi
>>>> | dyld: Library not loaded:
>>>>/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.
>>>>dylib
>>>> |   Referenced from:
>>>> | 
>>>>/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.
>>>>3.0/bin/g.parser
>>>> |   Reason: image not found
>>>> | make: *** [d.rast.leg.tmp.html] Error 1
>>>> | rm d.rast.leg.tmp.html
>>>> | bash-4.3$
>>>> `----
>>>> 
>>>> In other words: grass is looking during the compilation for a dynamic
>>>> library
>>>> 
>>>>(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn
>>>>.dylib)
>>>> which has been created, but will only be there when installing.
>>>> 
>>>> Also important: this error only occurs when the html manual pages are
>>>> created!
>>>> 
>>>> Cheers,
>>>> 
>>>> Rainer
>>>> 
>>>> 
>>>> Rainer M Krug <Rainer 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.com_&d=C
>wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8
>wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h_V7mJ
>Bf8t6V3mbREBfgUP8u90&e=
>
>"Oh, look, I seem to have fallen down a deep, dark hole.  Now what does
>that remind me of?  Ah, yes - life."
>
>- Marvin
>
>
>_______________________________________________
>grass-user mailing list
>grass-user at lists.osgeo.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mailma
>n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLt
>SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rF
>c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e= 