[GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)
Rainer M Krug
Rainer at krugs.de
Thu Mar 17 01:28:13 PDT 2016
Michael Barton <Michael.Barton at asu.edu> writes:
> I've held off updating to make sure I could continue to provide
> binaries for the GRASS community. If you are right, I will upgrade one
> of my computers to the new OS and try this. SIP off and compile.
Pleas note that I used homebrew to install.
As William mentions in his email
http://permalink.gmane.org/gmane.comp.gis.grass.user/53067 :
,----
| Why it's working for Rainer's compiled GRASS at runtime is because all
| the GRASS libraries and executables and dependencies have the same
| embedded paths as where they are installed. DYLD_LIBRARY_PATH is
| still ignored from SIP, but it's not needed.
`----
I can't speak for the binary app here (.dmg).
Concerning homebrew: they provide so called "bottles" which are
binaries. I *think* that one could create a bottle of GRASS, and it
could be installed by everybody without having to go through the SIP
disable - compile - enable shlep. But this would only apply to the
default set of config options.
My main question is now: can we get rid of DYLD_LIBRARY_PATH for
*compiling*? This would make GRASS compilable again on El Capitan with homebrew.
Any suggestions?
Rainer
P.S: there seems to quite a group of developers out there who say in
general that DYLD_LIBRARY_PATH and DYLD_... are bad and should be
avoided. Would that be possible for GRASS, or require a large amount of work?
>
> The question then is whether users need to turn SIP off to install in the normal applications folder.
>
> Michael
> ____________________
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> Arizona State University
>
> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> On Mar 16, 2016, at 12:24 PM, Rainer M Krug <Rainer at krugs.de> wrote:
>>
>> 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
>
> _______________________________________________
> 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/20160317/4efbf133/attachment.sig>
More information about the grass-user
mailing list