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
signature.asc
Description: PGP signature
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
