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" <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
