[GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)
Rainer M Krug
Rainer at krugs.de
Wed Mar 16 02:32:04 PDT 2016
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?
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/cb0fd65d/attachment-0001.sig>
More information about the grass-user
mailing list