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-darwin15 >>>>> .3.0/scripts/d.rast.leg" >>>>> | != "" ] ; then >>>>> | >>>>> GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar >>>>> 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-dar >>>>> 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/dist. >>>>> x86_64-apple-darwin15.3.0/scripts:$PATH" >>>>> | >>>>> PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app >>>>> le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5ar/ >>>>> dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH" >>>>> | >>>>> DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86 >>>>> _64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/ >>>>> dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344- >>>>> 1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-71201 >>>>> 60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/gra >>>>> 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-darwin15. >>>>> 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.svn. >>>>> dylib >>>>> | Referenced from: >>>>> | >>>>> /private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15. >>>>> 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.svn >>>>> .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=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8 >> wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc&s=4w5wYepEPeebD54T1h_V7mJ >> 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_mailma >> n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLt >> SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rF >> c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e= > > _______________________________________________ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user ----- William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "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
