[GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Rainer M Krug]

William Kyngesburye <woklist at kyngchaos.com> writes:

> On Mar 15, 2016, at 2:05 PM, Rainer M Krug <Rainer at krugs.de> wrote:
>> 
>> William Kyngesburye <woklist at 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 <Rainer at 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 <Rainer at krugs.de> writes:
>>>> 
>>>>> Adam Dershowitz <adershowitz at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20160316/8d95a336/attachment.sig>