William Kyngesburye <wokl...@kyngchaos.com> writes: > 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.
So the correct approach would be to eliminate the use of DYLD_LIBRARY_PATH completely from GRASS for the make process? As the final grass executable does not sit in /bin or /usr/bin (therefore not considered a "protected binary), DYLD_LIBRARY_PATH should work. Correct? Maybe this is the reason, why Macports compiles correctly, if it uses an own make? Or is there a different solution? > >>> >>> 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. OK - then it is here to stay. > >>> 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. OK. > >> 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. OK > >>> 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-darwin15.3.0/demolocation/.grassrc71 >>>> | >>>> GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0 >>>> | >>>> 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:$PATH" >>>> | >>>> PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-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-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/grass-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> > http://www.kyngchaos.com/ > > "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 > 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
