[GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)
Adam Dershowitz
adershowitz at exponent.com
Tue Mar 15 13:59:22 PDT 2016
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
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
>
>
More information about the grass-user
mailing list