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

William Kyngesburye woklist at kyngchaos.com
Tue Mar 15 13:43:16 PDT 2016 

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-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= 
> 
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

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

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

- Marvin

More information about the grass-user mailing list