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

Rainer M Krug Rainer at krugs.de
Wed Mar 16 03:24:15 PDT 2016 

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://developer.apple.com/library/mac/documentation/Security/Conceptual/S
>> ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html
>>
>
> Which seems to be the reason why during the make step (make is in
> /usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is
> ignored.
>
> But when running GRASS, it should work.
>
> Has anybody tried out to
>
> 1) disable SIP
> 2) compile GRASS from source
> 3) install GRASS
> 4) enable SIP
>
> and does it run?


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


>
> Do you know if Macports uses an own make (and possibly other tools?), or
> the one supplied by OS X?
>
>
>> So, would it be possible to just just the paths that are used for the
>> search paths in the Application bundle itself?
>>
>> -- Adam
>>
>>
>>
>>
>>
>>
>> On 3/15/16, 4:43 PM, "William Kyngesburye" <woklist 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-darwin
>>>>>>>>15
>>>>>>>> .3.0/scripts/d.rast.leg"
>>>>>>>> | != "" ] ; then
>>>>>>>> | 
>>>>>>>> 
>>>>>>>>GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
>>>>>>>>ar
>>>>>>>> win15.3.0/demolocation/.grassrc71
>>>>>>>> | 
>>>>>>>> 
>>>>>>>>GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple
>>>>>>>>-d
>>>>>>>> arwin15.3.0
>>>>>>>> | 
>>>>>>>> 
>>>>>>>>PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
>>>>>>>>ar
>>>>>>>> 
>>>>>>>>win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64
>>>>>>>>-a
>>>>>>>> 
>>>>>>>>pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dis
>>>>>>>>t.
>>>>>>>> x86_64-apple-darwin15.3.0/scripts:$PATH"
>>>>>>>> | 
>>>>>>>> 
>>>>>>>>PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
>>>>>>>>pp
>>>>>>>> 
>>>>>>>>le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5a
>>>>>>>>r/
>>>>>>>> dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
>>>>>>>> | 
>>>>>>>> 
>>>>>>>>DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x
>>>>>>>>86
>>>>>>>> 
>>>>>>>>_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5a
>>>>>>>>r/
>>>>>>>> 
>>>>>>>>dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-4734
>>>>>>>>4-
>>>>>>>> 
>>>>>>>>1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-712
>>>>>>>>01
>>>>>>>> 
>>>>>>>>60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/g
>>>>>>>>ra
>>>>>>>> ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
>>>>>>>> | LC_ALL=C
>>>>>>>> | 
>>>>>>>> 
>>>>>>>>/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
>>>>>>>>5.
>>>>>>>> 3.0/scripts/d.rast.leg
>>>>>>>> | --html-description < /dev/null | grep -v '</body>\|</html>' >
>>>>>>>> | d.rast.leg.tmp.html ; fi
>>>>>>>> | dyld: Library not loaded:
>>>>>>>> 
>>>>>>>>/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.sv
>>>>>>>>n.
>>>>>>>> dylib
>>>>>>>> |   Referenced from:
>>>>>>>> | 
>>>>>>>> 
>>>>>>>>/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin1
>>>>>>>>5.
>>>>>>>> 3.0/bin/g.parser
>>>>>>>> |   Reason: image not found
>>>>>>>> | make: *** [d.rast.leg.tmp.html] Error 1
>>>>>>>> | rm d.rast.leg.tmp.html
>>>>>>>> | bash-4.3$
>>>>>>>> `----
>>>>>>>> 
>>>>>>>> In other words: grass is looking during the compilation for a
>>>>>>>>dynamic
>>>>>>>> library
>>>>>>>> 
>>>>>>>> 
>>>>>>>>(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.s
>>>>>>>>vn
>>>>>>>> .dylib)
>>>>>>>> which has been created, but will only be there when installing.
>>>>>>>> 
>>>>>>>> Also important: this error only occurs when the html manual pages
>>>>>>>>are
>>>>>>>> created!
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> 
>>>>>>>> Rainer
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Rainer M Krug <Rainer 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=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rC
>>>>>n8
>>>>> 
>>>>>wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h_V7
>>>>>mJ
>>>>> Bf8t6V3mbREBfgUP8u90&e=
>>>>> 
>>>>> "Oh, look, I seem to have fallen down a deep, dark hole.  Now what does
>>>>> that remind me of?  Ah, yes - life."
>>>>> 
>>>>> - Marvin
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> grass-user mailing list
>>>>> grass-user 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=5usL3OGqXabR
>>>>>Lt
>>>>> 
>>>>>SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-
>>>>>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_mailm
>>>>an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabR
>>>>LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4
>>>>CZvY&s=dFMvzAURv7ExJqKWuHhJuiWSp1tVxWAQLXdLERfRUcY&e=
>>>
>>>-----
>>>William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_&d=C
>>>wIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8
>>>wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwjWw1t
>>>6syI0zj0Ou2szNtTSNWQ&e=
>>>
>>>"I ache, therefore I am.  Or in my case - I am, therefore I ache."
>>>
>>>- Marvin
>>>
>>>
>>
>> _______________________________________________
>> grass-user mailing list
>> grass-user 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/20160316/eb3f83eb/attachment.sig>

More information about the grass-user mailing list