[GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)
Adam Dershowitz
adershowitz at exponent.com
Wed Mar 16 06:03:46 PDT 2016
On 3/16/16, 6:24 AM, "Rainer M Krug" <Rainer at krugs.de> wrote:
>Rainer M Krug <Rainer at krugs.de> writes:
>
>> Adam Dershowitz <adershowitz at 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/Conceptua
>>>l/S
>>>
>>>ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.h
>>>tml
>>>
>>
>> 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.
Based on what you tried above I decided to try a different test: I just
disabled SIP, installed GRASS (from binaries), and then reenabled SIP and
found that it doesn’t work. So, the details of your compilation must be
different from that of the provided binaries. Yours are probably set for
just your computer (32/64 bit, OS version etc) while the binaries try to
work for everyone so make some of that determination at startup time.
>
>
>>
>> Do you know if Macports uses an own make (and possibly other tools?), or
>> the one supplied by OS X?
I think that the answer is that by default macport uses the Apple provided
make, but specific ports can require other ports as dependencies. And
those can include things like gmake etc. So, some ports do require
non-Apple versions….
That said, the grass7 port lists:
Build Dependencies: pkgconfig
Library Dependencies: freetype, fftw-3, gdal, geos, tiff, libpng, proj,
cairo, readline, python27, py27-pillow, wxPython-3.0,
py27-wxPython-3.0
While any of those could then require other ports, they look pretty
standard, so likely just use Apple supplied make.
But, I am not completely sure that about other make tools that macports
could use, but I think that the above is correct.
>>
>>
>>> 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" <woklist at 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
>>>>><adershowitz at exponent.com>
>>>>>wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
>>>>> <grass-user-bounces at lists.osgeo.org on behalf of
>>>>>woklist at kyngchaos.com>
>>>>> wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>>>
>>>>>>>> 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 <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-dar
>>>>>>>>>win
>>>>>>>>>15
>>>>>>>>> .3.0/scripts/d.rast.leg"
>>>>>>>>> | != "" ] ; then
>>>>>>>>> |
>>>>>>>>>
>>>>>>>>>GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-appl
>>>>>>>>>e-d
>>>>>>>>>ar
>>>>>>>>> win15.3.0/demolocation/.grassrc71
>>>>>>>>> |
>>>>>>>>>
>>>>>>>>>GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-ap
>>>>>>>>>ple
>>>>>>>>>-d
>>>>>>>>> arwin15.3.0
>>>>>>>>> |
>>>>>>>>>
>>>>>>>>>PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-appl
>>>>>>>>>e-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_6
>>>>>>>>>4-a
>>>>>>>>>pp
>>>>>>>>>
>>>>>>>>>le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1yb
>>>>>>>>>n5a
>>>>>>>>>r/
>>>>>>>>> dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
>>>>>>>>> |
>>>>>>>>>
>>>>>>>>>DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dis
>>>>>>>>>t.x
>>>>>>>>>86
>>>>>>>>>
>>>>>>>>>_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1yb
>>>>>>>>>n5a
>>>>>>>>>r/
>>>>>>>>>
>>>>>>>>>dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-4
>>>>>>>>>734
>>>>>>>>>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/tm
>>>>>>>>>p/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-darw
>>>>>>>>>in1
>>>>>>>>>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-darw
>>>>>>>>>in1
>>>>>>>>>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 <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>
>>>>>>
>>>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com
>>>>>>_&d
>>>>>>=C
>>>>>>
>>>>>>wIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn
>>>>>>6rC
>>>>>>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 at lists.osgeo.org
>>>>>>
>>>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_m
>>>>>>ail
>>>>>>ma
>>>>>>
>>>>>>n_listinfo_grass-2Duser&d=CwIGaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqX
>>>>>>abR
>>>>>>Lt
>>>>>>
>>>>>>SzGmh8YEvbco28TaiOmWcn6rCn8wM&m=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1b
>>>>>>up-
>>>>>>rF
>>>>>> c&s=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo&e=
>>>>>
>>>>> _______________________________________________
>>>>> grass-user mailing list
>>>>> grass-user at lists.osgeo.org
>>>>>
>>>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_ma
>>>>>ilm
>>>>>an_listinfo_grass-2Duser&d=CwIFaQ&c=t0wRGL5ICVzH157W8C8Wew&r=5usL3OGqX
>>>>>abR
>>>>>LtSzGmh8YEvbco28TaiOmWcn6rCn8wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_T
>>>>>Of4
>>>>>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=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6r
>>>>Cn8
>>>>wM&m=wBZVhJR1Vijar8vPd0vMw-5LMplYPnRZhF_TOf4CZvY&s=GvawdpD6TkYdZwsdpwjW
>>>>w1t
>>>>6syI0zj0Ou2szNtTSNWQ&e=
>>>>
>>>>"I ache, therefore I am. Or in my case - I am, therefore I ache."
>>>>
>>>>- 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
More information about the grass-user
mailing list