Michael Barton <michael.bar...@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 <rai...@krugs.de> wrote: >> >> Rainer M Krug <rai...@krugs.de> writes: >> >>> Adam Dershowitz <adershow...@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" <wokl...@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 <adershow...@exponent.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye" >>>>>> <grass-user-boun...@lists.osgeo.org on behalf of wokl...@kyngchaos.com> >>>>>> wrote: >>>>>> >>>>>>> On Mar 15, 2016, at 2:05 PM, Rainer M Krug <rai...@krugs.de> wrote: >>>>>>>> >>>>>>>> William Kyngesburye <wokl...@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 <rai...@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 <rai...@krugs.de> writes: >>>>>>>>>> >>>>>>>>>>> Adam Dershowitz <adershow...@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@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@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@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982
signature.asc
Description: PGP signature
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
