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