Re: [GRASS-dev] New attempt to update GRASS for Mac
; Arizona State University >>> >>> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) >>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> On Jul 28, 2017, at 12:09 PM, Michael Barton <michael.bar...@asu.edu> >>>> wrote: >>>> >>>> Previously, we needed to set this path to compile GRASS so that it worked >>>> with wxPython wrappers for wxWidgets. I will do a new compile without this >>>> argument and see what happens. >>>> >>>> In any case, I need to be able to make sure that GRASS uses the wxPython >>>> that is bundled with it by default to avoid differences in versions and >>>> SIP issues. >>>> >>>> Michael >>>> >>>> C. Michael Barton >>>> Director, Center for Social Dynamics & Complexity >>>> Professor of Anthropology, School of Human Evolution & Social Change >>>> Head, Graduate Faculty in Complex Adaptive Systems Science >>>> Arizona State University >>>> >>>> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) >>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> On Jul 28, 2017, at 7:56 AM, Vaclav Petras <wenzesl...@gmail.com> wrote: >>>>> >>>>> >>>>> >>>>> On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton <michael.bar...@asu.edu> >>>>> wrote: >>>>> > >>>>> > The other issue I'm hitting is that the configure argument to enable >>>>> > wxPython, '-with-wxwidgets=' expects a path to a wx_config file. >>>>> > AFAICT, wxPython 4 does not have such a file. And I can't yet find >>>>> > anything that seems to serve the same function. I can put in a path to >>>>> > the folder/directory where the wxPython 4 files live. While this >>>>> > compiles without error, I don't think it is using wxPython 4. >>>>> > >>>>> >>>>> --with-wxwidgets= is for wxWidgets (C++ library), not wxPython (its >>>>> Python wrapper), so you don't need to use at all. wxPython must be part >>>>> of the Python installation you are using. >>>>> >>>> >>> >> > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects." - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New attempt to update GRASS for Mac
I think the intent was to be able to customize python and pythonw separately, if only to have that possibility, I don't remember if there was a specific reason. > On Jul 28, 2017, at 3:13 PM, Michael Barton <michael.bar...@asu.edu> wrote: > > I had to hack python_wrapper to the following: > > if [ -z "$GISBASE" ] ; then > echo "You must be in GRASS GIS to run this program." >&2 > exit 1 > fi > > SYSARCH=`uname -p` > SYSVER=`uname -r | cut -d . -f 1` > > if [ ! "$GRASS_PYTHONWX" ] ; then > GRASS_PYTHONWX="pythonw" > fi > > exec "$GRASS_PYTHONWX" "$@" > > > I don't know what GRASS_PYTHONWX does that GRASS_PYTHON does not do. > > Michael > > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Head, Graduate Faculty in Complex Adaptive Systems Science > Arizona State University > > voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) > fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) > www: http://www.public.asu.edu/~cmbarton > <http://www.public.asu.edu/~cmbarton>, http://csdc.asu.edu > <http://csdc.asu.edu/> > > > > > > > > > > > > > > >> On Jul 28, 2017, at 2:06 PM, William Kyngesburye <wokl...@kyngchaos.com >> <mailto:wokl...@kyngchaos.com>> wrote: >> >> Maybe it's the python wrapper - it does 2 things: force python to run 32bit >> if wxpython is 32bit, and run pythonw that wxpython needs. There is a 2nd >> env var to set pythonw (I think it's only used here): GRASS_PYTHONWX. >> >>> On Jul 28, 2017, at 2:49 PM, Michael Barton <michael.bar...@asu.edu >>> <mailto:michael.bar...@asu.edu>> wrote: >>> >>> ARGGH! >>> >>> Set up and activated virtual environment in conda >>> Ensured that Anaconda Python is default >>> Ensured that Anaconda wxPython 4 is default >>> Compiled GRASS trunk in this environment >>> Launched the app created and... >>> >>> Launching GUI in the background, please wait... >>> GRASS 7.3.svn (nc_spm_08_grass7):~ > python >>> Python 2.7.10 (default, Feb 7 2017, 00:08:15) >>> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin >>> Type "help", "copyright", "credits" or "license" for more information. >>> >>> import wx >>> >>> import wxversion >>> >>> wx.VERSION_STRING >>> '3.0.2.0' >>> >>> >>> >>> Using my system Python and system wxPython >>> >>> Michael >>> >>> C. Michael Barton >>> Director, Center for Social Dynamics & Complexity >>> Professor of Anthropology, School of Human Evolution & Social Change >>> Head, Graduate Faculty in Complex Adaptive Systems Science >>> Arizona State University >>> >>> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) >>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>> www: http://www.public.asu.edu/~cmbarton >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=DwMFAg=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=BePmQvHoak5xlL1EvjF6leyzps0b-NaCbBHQvvipy0o=_csIynda46fLrto5tgTY45hzaeR_3subkBE0NlQ6dJM=>, >>> http://csdc.asu.edu >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu_=DwMFAg=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=BePmQvHoak5xlL1EvjF6leyzps0b-NaCbBHQvvipy0o=eb_Wwy_PkOFHe76953UsBPByTCPfg5EYVkgipGiQ76A=> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> On Jul 28, 2017, at 12:09 PM, Michael Barton <michael.bar...@asu.edu >>>> <mailto:michael.bar...@asu.edu>> wrote: >>>> >>>> Previously, we needed to set this path to compile GRASS so that it worked >>>> with wxPython wrappers for wxWidgets. I will do a new compile without this >>>> argument and see what happens. >>>> >>>> In any case, I need to be able to make sure that GRASS uses the wxPython >>>> that is bundled with it by default to avoid differences in versions and >>>> SIP issues. >>>>
Re: [GRASS-dev] New attempt to update GRASS for Mac
Maybe it's the python wrapper - it does 2 things: force python to run 32bit if wxpython is 32bit, and run pythonw that wxpython needs. There is a 2nd env var to set pythonw (I think it's only used here): GRASS_PYTHONWX. > On Jul 28, 2017, at 2:49 PM, Michael Barton <michael.bar...@asu.edu> wrote: > > ARGGH! > > Set up and activated virtual environment in conda > Ensured that Anaconda Python is default > Ensured that Anaconda wxPython 4 is default > Compiled GRASS trunk in this environment > Launched the app created and... > > Launching GUI in the background, please wait... > GRASS 7.3.svn (nc_spm_08_grass7):~ > python > Python 2.7.10 (default, Feb 7 2017, 00:08:15) > [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import wx > >>> import wxversion > >>> wx.VERSION_STRING > '3.0.2.0' > >>> > > Using my system Python and system wxPython > > Michael > > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Head, Graduate Faculty in Complex Adaptive Systems Science > Arizona State University > > voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) > fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) > www: http://www.public.asu.edu/~cmbarton > <http://www.public.asu.edu/~cmbarton>, http://csdc.asu.edu > <http://csdc.asu.edu/> > > > > > > > > > > > > > > >> On Jul 28, 2017, at 12:09 PM, Michael Barton <michael.bar...@asu.edu >> <mailto:michael.bar...@asu.edu>> wrote: >> >> Previously, we needed to set this path to compile GRASS so that it worked >> with wxPython wrappers for wxWidgets. I will do a new compile without this >> argument and see what happens. >> >> In any case, I need to be able to make sure that GRASS uses the wxPython >> that is bundled with it by default to avoid differences in versions and SIP >> issues. >> >> Michael >> >> C. Michael Barton >> Director, Center for Social Dynamics & Complexity >> Professor of Anthropology, School of Human Evolution & Social Change >> Head, Graduate Faculty in Complex Adaptive Systems Science >> Arizona State University >> >> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) >> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >> www: http://www.public.asu.edu/~cmbarton >> <http://www.public.asu.edu/~cmbarton>, http://csdc.asu.edu >> <http://csdc.asu.edu/> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> On Jul 28, 2017, at 7:56 AM, Vaclav Petras <wenzesl...@gmail.com >>> <mailto:wenzesl...@gmail.com>> wrote: >>> >>> >>> >>> On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton <michael.bar...@asu.edu >>> <mailto:michael.bar...@asu.edu>> wrote: >>> > >>> > The other issue I'm hitting is that the configure argument to enable >>> > wxPython, '-with-wxwidgets=' expects a path to a wx_config file. AFAICT, >>> > wxPython 4 does not have such a file. And I can't yet find anything that >>> > seems to serve the same function. I can put in a path to the >>> > folder/directory where the wxPython 4 files live. While this compiles >>> > without error, I don't think it is using wxPython 4. >>> > >>> >>> --with-wxwidgets= is for wxWidgets (C++ library), not wxPython (its Python >>> wrapper), so you don't need to use at all. wxPython must be part of the >>> Python installation you are using. >>> >> > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "We can die but once, and that once we must die. To be always fearing, then, would not avert it, and would make life miserable." - Tarzan, on death ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS on OS X El Capitan - slowly dying or is something happening?
Right, forgot about that part in make (even though I pointed it out previously). Yeah, that would be messy - it would have to compile with the temporary path, then use install_name_tool at install to change all the paths. This is where I got stalled with figuring out loops and lists of modules and libraries in make. Another option that may be simpler is to move the doc generation to install, then everything runs from the install path. > On Jan 21, 2016, at 3:01 AM, Rainer M Krug <rai...@krugs.de> wrote: > > William Kyngesburye <wokl...@kyngchaos.com> writes: > >> There are a couple ideas floating around. >> >> I'm surprised Homebrew has a problem. Since it would leave everything >> in the configured location (/usr/local), there should not be library >> paths pointing somewhere else that would need DYLD_LIBRARY_PATH to >> divert. > > homebrew is compiling in a temporary location, and than installing it to > /usr/local/Cellar/. > > The problem is the same why I had to install and than compile again: > > , > | bash-4.3$ make > | if [ > "/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts/d.out.file" > != "" ] ; then > GISRC=/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/demolocation/.grassrc70 > > GISBASE=/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0 > > PATH="/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts:$PATH" > > PYTHONPATH="/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/etc/python:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/gui/wxpython:$PYTHONPATH" > > DYLD_LIBRARY_PATH="/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib:" > LC_ALL=C > /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts/d.out.file > --html-description < /dev/null | grep -v '\|' > > d.out.file.tmp.html ; fi > | dyld: Library not loaded: > /usr/local/Cellar/grass-70/7.0.1/grass-7.0.1/lib/libgrass_gis.7.0.1.dylib > | Referenced from: > /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin/g.parser > | Reason: image not found > | make: *** [d.out.file.tmp.html] Error 1 > | rm d.out.file.tmp.html > | bash-4.3$ > ` > > During make, the html documentation is created. For this, > libgrass_gis.7.0.1.dylib is needed. It is already compiled, but not > installed. > > It is in > > , > | bash-4.3$ ls -la > /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib/libgrass_gis* > | -rwxr-xr-x 1 rainerkrug wheel 218244 Jan 21 09:37 > /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib/libgrass_gis.7.0.1.dylib > | lrwxr-xr-x 1 rainerkrug wheel 24 Jan 21 09:37 > /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib/libgrass_gis.dylib > -> libgrass_gis.7.0.1.dylib > | bash-4.3$ > ` > > And I assume the path where it is located is in the DYNLIB_ variable > which is ignored. > > This problem should be solvable, when somehow the path to the compiled > (but not installed) could be temporarily added during the make. > > Any suggestions how this could be done? > > Rainer > >> >>> On Jan 20, 2016, at 8:37 AM, Rainer M Krug <rai...@krugs.de> wrote: >>> >>> Hi >>> >>> Sorry for this blunt subject - but I am wondering if anybody is looking >>> at supporting El Capitan without having to disable SIP (System Integrity >>> Protection). SIP is likely to stay, and for many (including myself) >>> disabling SIP is not really an option as it goes to deep into the OS. >>> >>> >>> So my personal opinion: if GRASS want's to stay relevant on OS X, a >>> solution needs to be found to compile and install it on a mac as easy >>> as it was before (homebrew, which I relly like, and also the frameworks >>> From William Kyngesburye and michael Barton?) >
Re: [GRASS-dev] GRASS on OS X El Capitan - slowly dying or is something happening?
There are a couple ideas floating around. I'm surprised Homebrew has a problem. Since it would leave everything in the configured location (/usr/local), there should not be library paths pointing somewhere else that would need DYLD_LIBRARY_PATH to divert. > On Jan 20, 2016, at 8:37 AM, Rainer M Krug <rai...@krugs.de> wrote: > > Hi > > Sorry for this blunt subject - but I am wondering if anybody is looking > at supporting El Capitan without having to disable SIP (System Integrity > Protection). SIP is likely to stay, and for many (including myself) > disabling SIP is not really an option as it goes to deep into the OS. > > > So my personal opinion: if GRASS want's to stay relevant on OS X, a > solution needs to be found to compile and install it on a mac as easy > as it was before (homebrew, which I relly like, and also the frameworks > From William Kyngesburye and michael Barton?) > > I mean - I have found a way of compiling GRASS 7.1 (see my post from the > 07 January in the topic "SUCCESS (running): Compiling grass 7 svn trunk > on OS X El Capitan") which gives me a working GRASS GIS including GUI, > but this is not really a solution. > > I asked for help but did not get any response (subject "grass 7 svn > trunk on OS X El Capitan - need help"). > > So I would like to know if somebody would be prepared to help or at > least tell me if I am following the wrong track. I am not very > experienced in compiling / linking / make files but I have a basic > understanding. > > I simply refuse to accept that GRASS will die for OSX users (>= El > Capitan). > > Cheers, > > Rainer > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Centre of Excellence for Invasion Biology > Stellenbosch University > South Africa > > Tel : +33 - (0)9 53 10 27 44 > Cell: +33 - (0)6 85 62 59 98 > Fax : +33 - (0)9 58 10 27 44 > > Fax (D):+49 - (0)3 21 21 25 22 44 > > email: rai...@krugs.de > > Skype: RMkrug > > PGP: 0x0F52F982 > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Compiling grass 7 svn trunk on OS X
It's probably the new SIP security protection, which makes executables ignore DYLD_LIBRARY_PATH. Part of GRASS compilation is to run the modules to generate help files. Since they're not in their install location yet, DYLD_LIBRARY_PATH is needed for them to find the GRASS libraries, but DYLD_LIBRARY_PATH is now ignored, and it fails. One option is to disable SIP before compilation and reenble it after installation. I haven't upgraded to El Capitan yet so I don't know the exact way to do this. Probably in System Prefs-Security. > On Jan 6, 2016, at 11:06 AM, Rainer M Krug <rai...@krugs.de> wrote: > > Hi > > I am trying to compile GRASS 7 from svn on OS X El Capitan. I have ... > , > | 5:37:13 ~/ownCompiled/grass/grass7_trunk/scripts/d.correlate$ make > | if [ > "/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts/d.correlate" > != "" ] ; then > GISRC=/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/demolocation/.grassrc71 > > GISBASE=/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0 > > PATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts:$PATH" > > PYTHONPATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/etc/python:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/gui/wxpython:$PYTHONPATH" > > DYLD_LIBRARY_PATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/lib:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/lib:" > LC_ALL=C > /Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts/d.correlate > --html-description < /dev/null | grep -v '\|' > > d.correlate.tmp.html ; fi > | dyld: Library not loaded: > /Applications/GRASS-7.1.app/Contents/MacOS/lib/libgrass_gis.7.1.svn.dylib > | Referenced from: > /Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin/g.parser > | Reason: image not found > | make: *** [d.correlate.tmp.html] Error 1 > | rm d.correlate.tmp.html > ` > > What irritates me is the error message concerning not being able to > load - which is obvious, as I am still compiling GRASS and haven't > installed it yet. - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WARNING TO MAC USERS - WAIT UPDATING TO EL CAPITAN (OS X 10.11)
My thought is that it's a packaging problem. As it is, the GRASS source should run on El Cap, with a simple configure-make-install and no packaging. It will use external libraries in their installed locations, which should work in El Cap. The problem comes when some of those external libraries are bundled inside the app without any modification (ie wxPython). Those libraries still have their embedded install locations which would normally break other software (and is not related to the El Capitan problem), but GRASS sets DYLD_LIBRARY_PATH to get around this (I don't know the original reason for this, but it makes the package moveable/renamable). DYLD_LIBRARY_PATH is where the El Cap problem comes in - as part of new security features the system now ignores this. 2 possible solutions, both on the packaging end: - compile the external libraries (before compiling GRASS) as if they are embedded in the GRASS app. That is, configure the prefix to be inside the to-be-installed GRASS app. - post-process the libraries when bundled to update the embedded library paths. The first is simple, but has a couple drawbacks: the app is not moveable (minor) because it still depends on the full paths embedded in the libraries and GRASS, and this doesn't work with premade binaries of the libraries (like wxPython). The second is harder, but can be done to any bundled library or tool, and the paths can be made relative to make the app movable/renamable. Though the movablility part would be best supplemented by changes in the GRASS source makefiles to make GRASS have all relative paths (this is what I was originally looking at, that stalled me). At a minimum, and the simplest, full paths should be changed in the bundled external libraries, by either or both methods. > On Dec 4, 2015, at 2:09 PM, Brian Miles <selimna...@gmail.com> wrote: > > Michael, William, > > I'd like to take a look at this to see if I can help. I'm not an expert in > makefiles, or linkers, but I'm willing to put some time in to help move the > ball forward. Is there a synopsis of the problem so I don't have to start > from square one? > > Thanks, > > Brian > >> On Dec 4, 2015, at 2:47 PM, Michael Barton <michael.bar...@asu.edu> wrote: >> >> This is still not resolved. William Kyngesburye has suggested some ways >> forward, but we are not yet sure exactly what causes the failure. Help is >> appreciated. >> >> Michael >> >> C. Michael Barton >> Director, Center for Social Dynamics & Complexity >> Professor of Anthropology, School of Human Evolution & Social Change >> Head, Graduate Faculty in Complex Adaptive Systems Science >> Arizona State University >> >> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) >> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> On Dec 4, 2015, at 12:36 PM, Brian Miles <selimna...@gmail.com> wrote: >>> >>> Michael, >>> >>> Just wondering what the status is on this. Is there a ticket describing >>> the problems with OS X 10.11 and GRASS, and hopefully tracking the progress >>> to a fix? I tried searching the tickets (http://trac.osgeo.org/grass/), >>> but wasn't able to filter out enough false positives. >>> >>> Thanks, >>> >>> Brian Miles >>> Research Scientist >>> Institute for the Environment >>> University of North Carolina at Chapel Hill >>> >>>> On Oct 8, 2015, at 8:14 PM, grass-dev-requ...@lists.osgeo.org wrote: >>>> >>>> From: Michael Barton <michael.bar...@asu.edu> >>>> Date: October 8, 2015 at 8:07:58 PM EDT >>>> To: GRASS developers grass-developers <grass-dev@lists.osgeo.org>, >>>> "grass-user grass-user" <grass-u...@lists.osgeo.org> >>>> Subject: [GRASS-dev] WARNING TO MAC USERS - WAIT UPDATING TO EL CAPITAN >>>> (OS X 10.11) >>>> >>>> >>>> I've had reports of GRASS not running for users updating to El Capitan. >>>> There is a possible workaround, but it is cumbersome and not guaranteed to >>>> work. I recommend that you do wait to update while we try to solve this. >>>> >>>> I've also heard that El Capitan breaks R. >>>> >>>> Michael >>>> >>>> C. Michael Barton >>>> Director, Center for Social Dynamics & Complexity >>>> Professor of Anthropology, School of Human Evolution & Social Change >>>> Head, Graduate Faculty in Complex Adaptive Systems Science >>>> Arizona State University >>>> >>>> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) >>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>> >> > - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] linking update for OS X - makefile help needed
To get GRASS working in the latest OS X, El Capitan/10.11, I believe the key is
that the SIP security ignores DYLD_LIBRARY_PATH (an easy code injection
method). So, library linking needs to be relative, with @loader_path and
@executable_path. This change will still work on older OS X versions.
Libraries and loadable modules (like db drivers) should link to other libraries
with @loader_path. I got the library part figured out - change the
install_name in SHLIB_LD set in configure.
The drivers and executables (both modules and etc helpers) is where it gets
messy. When linked normally, they will link the @loader_path/libname.dylib as
now set in the libraries, but this won’t work. So they need to be changed,
install_name_tool is what will do this. Ideally the makefile should loop
through only the dependent GRASS libraries and change them to a relative
@executable_path. I think the place to do this, for modules at least, is in
Module.make, after the linking step, but there I’m stuck. The GRASS makefiles
are doing things beyond my basic makefile skills.
The (shell) command needed is something like:
install_name_tool -change @loader_path/{LIBNAME}.dylib
@executable_path/../lib/{LIBNAME}.dylib /path/to/executable
the ../lib works for standard modules that are one-deep in the module type
subfolders and the top levels of etc/ and drivers/, but would need to be
adjusted to backtrack more for the db drivers and etc/ subfolder helpers. For
loaded items like the drivers, the @executable_path part should be @loader_path.
Can the makefile gurus get me started on something I can test?
-
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"I ache, therefore I am. Or in my case - I am, therefore I ache."
- Marvin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS will not not find laslib
t;>>>>> -I/Library/Frameworks/UnixImageIO.framework/Headers -arch i386 -arch
>>>>>>> x86_64 -isysroot /Developer/SDKs/MacOSX10.7.sdk -L/usr/local/lib
>>>>>>> conftest.c -L/usr/local/lib -llas -llas_c
>>>>>>> -L/Users/cmbarton/grass_source/LAS/boostlib/lib
>>>>>>> /Users/cmbarton/grass_source/LAS/boostlib/lib/libboost_program_options.a
>>>>>>> /Users/cmbarton/grass_source/LAS/boostlib/lib/libboost_thread.a
>>>>>>> /Library/Frameworks/GDAL.framework/unix/lib/libgdal.dylib
>>>>>>> /Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib
>>>>>>> /Library/Frameworks/UnixImageIO.framework/unix/lib/libtiff.dylib 1>&5
>>>>>>> ld: warning: ld: warning: ld: warning: ignoring file
>>>>>>> /usr/local/lib/liblas.dylib, file was built for x86_64 which is not the
>>>>>>> architecture being linked (i386): /usr/local/lib/liblas.dylibignoring
>>>>>>> file /usr/local/lib/liblas_c.dylib, file was built for x86_64 which is
>>>>>>> not the architecture being linked (i386):
>>>>>>> /usr/local/lib/liblas_c.dylibignoring file
>>>>>>> /Users/cmbarton/grass_source/LAS/boostlib/lib/libboost_program_options.a,
>>>>>>> file was built for archive which is not the architecture being linked
>>>>>>> (i386):
>>>>>>> /Users/cmbarton/grass_source/LAS/boostlib/lib/libboost_program_options.a
>>>>>>>
>>>>>>>
>>>>>>> ld: warning: ignoring file
>>>>>>> /Users/cmbarton/grass_source/LAS/boostlib/lib/libboost_thread.a, file
>>>>>>> was built for archive which is not the architecture being linked
>>>>>>> (i386): /Users/cmbarton/grass_source/LAS/boostlib/lib/libboost_thread.a
>>>>>>> Undefined symbols for architecture i386:
>>>>>>> "_LASReader_Create", referenced from:
>>>>>>> _main in conftest-68543b.o
>>>>>>> ld: symbol(s) not found for architecture i386
>>>>>>> clang: error: linker command failed with exit code 1 (use -v to see
>>>>>>> invocation)
>>>>>>> configure: failed program was:
>>>>>>> #line 6231 "configure"
>>>>>>> #include "confdefs.h"
>>>>>>> #include
>>>>>>> int main() {
>>>>>>> LASReader_Create("foo");
>>>>>>> ; return 0; }
>>>>>>>
>>>>>>>
>>>>>>> Anna, I'm happy to pass on tricks once I get them to actually work. I'm
>>>>>>> keeping notes.
>>>>>>>
>>>>>>> Thanks! I wonder if the problem can't be the line in the liblas config:
>>>>>>>
>>>>>>> -D CMAKE_OSX_ARCHITECTURES="x86_64" \
>>>>>>>
>>>>>>> how about this? (just a guess)
>>>>>>>
>>>>>>> -D CMAKE_OSX_ARCHITECTURES="x86_64;i386"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>> C. Michael Barton
>>>>>>> Director, Center for Social Dynamics & Complexity
>>>>>>> Professor of Anthropology, School of Human Evolution & Social Change
>>>>>>> Head, Graduate Faculty in Complex Adaptive Systems Science
>>>>>>> Arizona State University
>>>>>>>
>>>>>>> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>>>>>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
>>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Oct 8, 2015, at 3:07 PM, Anna Petrášová <kratocha...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 8, 2015 at 5:24 PM, Michael Barton
>>>>>>>> <michael.bar...@asu.edu> wrote:
>>>>>>>> With a lot of effort and some help, I've rebuilt liblas with new GDAL.
>>>>>>>> Now GRASS will not find liblas with the same configuration script that
>>>>>>>> I've used before. Here it is:
>>>>>>>>
>>>>>>>> Was there some specific trick that you could share?
>>>>>>>>
>>>>>>>> ./configure --with-macosx-sdk=/Developer/SDKs/MacOSX10.7.sdk
>>>>>>>> --with-freetype
>>>>>>>> --with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2
>>>>>>>> /Library/Frameworks/FreeType.framework/unix/include"
>>>>>>>> --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib
>>>>>>>> --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config
>>>>>>>> --with-proj
>>>>>>>> --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include
>>>>>>>> --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib
>>>>>>>> --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj
>>>>>>>> --with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config
>>>>>>>>
>>>>>>>> --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
>>>>>>>> --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
>>>>>>>> --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
>>>>>>>> --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
>>>>>>>> --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
>>>>>>>> --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
>>>>>>>> --with-cairo
>>>>>>>> --with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo
>>>>>>>> /Library/Frameworks/cairo.framework/unix/include"
>>>>>>>> --with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib
>>>>>>>> --with-cairo-ldflags="-lcairo" --without-postgres --without-mysql
>>>>>>>> --with-sqlite
>>>>>>>> --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib
>>>>>>>> --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include
>>>>>>>> --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include
>>>>>>>> --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x
>>>>>>>> --with-cxx --with-opengl=aqua --without-readline
>>>>>>>> --prefix=/Applications --enable-macosx-app --with-python
>>>>>>>> --with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.12.1/bin/wx-config
>>>>>>>> --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers
>>>>>>>> /Library/Frameworks/Tk.framework/Headers
>>>>>>>> /Library/Frameworks/Tk.framework/PrivateHeaders"
>>>>>>>> --with-tcltk-libs="/usr/local/tcltk_active/lib"
>>>>>>>> --with-macosx-archs="i386 x86_64"
>>>>>>>> --with-liblas="/usr/local/bin/liblas-config" --with-opencl --with-nls
>>>>>>>> --with-libs=/usr/local/lib --with-includes=/usr/local/include
>>>>>>>>
>>>>>>>> FWIW, here is the uninformative error. Any thoughts???
>>>>>>>>
>>>>>>>> There should be a log file from the configuration with more details,
>>>>>>>> not sure what's its name though.
>>>>>>>>
>>>>>>>>
>>>>>>>> checking for liblas-config... /usr/local/bin/liblas-config
>>>>>>>> configure: error: *** Unable to locate libLAS library.
>>>>>>>>
>>>>>>>> (yes liblas-config is exactly where I say it is)
>>>>>>>>
>>>>>>>> Michael
>>>>>>>>
>>>>>>>> C. Michael Barton
>>>>>>>> Director, Center for Social Dynamics & Complexity
>>>>>>>> Professor of Anthropology, School of Human Evolution & Social Change
>>>>>>>> Head, Graduate Faculty in Complex Adaptive Systems Science
>>>>>>>> Arizona State University
>>>>>>>>
>>>>>>>> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>>>>>>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
>>>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
-
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.in.lidar not running in Mac binaries for 7.1
> > /Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0/makefiles/CMakeFiles/progress.marks > /Applications/Xcode.app/Contents/Developer/usr/bin/make -f > CMakeFiles/Makefile2 all > /Applications/Xcode.app/Contents/Developer/usr/bin/make -f > src/CMakeFiles/las.dir/build.make src/CMakeFiles/las.dir/depend > cd /Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0/makefiles && > "/Applications/CMake 2.8-12.app/Contents/bin/cmake" -E cmake_depends "Unix > Makefiles" /Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0 > /Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0/src > /Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0/makefiles > /Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0/makefiles/src > /Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0/makefiles/src/CMakeFiles/las.dir/DependInfo.cmake > --color= > Scanning dependencies of target las > /Applications/Xcode.app/Contents/Developer/usr/bin/make -f > src/CMakeFiles/las.dir/build.make src/CMakeFiles/las.dir/build > "/Applications/CMake 2.8-12.app/Contents/bin/cmake" -E cmake_progress_report > /Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0/makefiles/CMakeFiles > 3 > [ 1%] Building CXX object src/CMakeFiles/las.dir/detail/index/indexcell.cpp.o > cd /Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0/makefiles/src > && /usr/bin/c++ -DHAVE_GDAL=1 -DHAVE_LIBGEOTIFF=1 -Dlas_EXPORTS > -stdlib=libstdc++ -Wextra -Wall -Wno-unused-parameter -Wno-unused-variable > -Wpointer-arith -Wcast-align -Wcast-qual -Wfloat-equal -Wredundant-decls > -Wno-long-long -O3 -DNDEBUG -arch “x86_64 -D > CMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.7.sdk” -fPIC > -I/Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0/src/../include > -I/Users/cmbarton/Dropbox/GRASS_dropbox/compiling/boost-snow/include > -I/Library/Frameworks/GDAL.framework/Headers > -I/Library/Frameworks/UnixImageIO.framework/unix/include -I/opt/local/include >-o CMakeFiles/las.dir/detail/index/indexcell.cpp.o -c > /Users/cmbarton/Dropbox/GRASS_dropbox/compiling/libLAS-1.8.0/src/detail/index/indexcell.cpp > clang: error: invalid arch name '-arch “x86_64' > make[2]: *** [src/CMakeFiles/las.dir/detail/index/indexcell.cpp.o] Error 1 > make[1]: *** [src/CMakeFiles/las.dir/all] Error 2 > make: *** [all] Error 2 > > > It looks like it is misreading the architecture flag value > > I’ve tried it without quotes around x86_64 and it acts like there are > unmatched quotes in the configure string. But there are not. Is there a bug > somewhere in a configure file? Where??? I can’t find any file with the > CMAKE_OSX_ARCHITECTURES flag to look at. > > I’m completely stumped. > > > > Michael > > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Head, Graduate Faculty in Complex Adaptive Systems Science > Arizona State University > > voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) > fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) > www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu > > > > > > > > > > > > > > > >> On Sep 16, 2015, at 7:22 AM, Vaclav Petras <wenzesl...@gmail.com> wrote: >> >> >> On Wed, Sep 16, 2015 at 9:41 AM, William Kyngesburye <wokl...@kyngchaos.com> >> wrote: >> So the question is if GRASS supports one or the other library or both, or >> does it also use the tools in a script so it doesn't matter. >> >> GRASS uses only the library, not the tools, and is designed/tested/known to >> work only with libLAS. >> >> I suppose there never was a need or will to compile it with LASlib which is >> coupled with partially non-FOSS LAStools (and you would need the FOSS >> libLAS' tools anyway). > - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.in.lidar not running in Mac binaries for 7.1
Looking closer at lastools/laslib and liblas, I think I got it partly right - the tools are funtionally the same between the two, but the libraries have very different headers (API). I was interested in getting las into my QGIS package, which uses the tools, not the library, and I didn't realize that difference. So the question is if GRASS supports one or the other library or both, or does it also use the tools in a script so it doesn't matter. As far as the linking goes, that embedded path to the library shouldn't matter since GRASS uses DYLD_LIBRARY_PATH to redirect linking. If it does still fail, maybe the library wasn't packaged with GRASS? On Sep 16, 2015, at 1:33 AM, Michael Barton <michael.bar...@asu.edu> wrote: > That’s what I’m using. I’d previously compiled libLAS with gdal 1.10. There > are a number of pieces to compiling libLAS in C++, including compiling Boost, > and a number of places for things to go wrong. > > Michael > > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Head, Graduate Faculty in Complex Adaptive Systems Science > Arizona State University > > voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) > fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) > www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu > > > > > > > > > > > > > > > >> On Sep 15, 2015, at 11:30 PM, Markus Neteler <nete...@osgeo.org> wrote: >> >> >> On Sep 16, 2015 4:40 AM, "Michael Barton" <michael.bar...@asu.edu> wrote: >> > >> > So far I'm stuck on compiling liblas with new gdal and no one has had any >> > advice for a way forward. >> >> Maybe stick to GDAL 1.11 for now? >> >> Markus >> > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New Mac binaries uploaded
laslib is liblas. On Aug 24, 2015, at 10:45 PM, Michael Barton michael.bar...@asu.edu wrote: That would be wonderful. I sort of got that impression too. But will the GRASS lidar tools be able to use LASlib instead of Liblas? Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Aug 24, 2015, at 8:40 PM, William Kyngesburye wokl...@kyngchaos.com wrote: I looked at LAS this spring. From what I found, libLAS is superceded by LASlib, found in LAStools. laslib and some of the tools are still opensource, but other tools are not. Laslib does not have a configure, it's a simple makefile that needs a little tweaking for OS X. And there appears to be no dependence on BOOST or Geotiff, or anything else. For laslib, all I needed to do was edit laslib/src/makefile and change these lines: COPTS = -Os -Wall -Wno-deprecated -DNDEBUG -DUNORDERED -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.7.sdk COMPILER = clang++ And in the liblas.a target, add a line after the cp line (tha's a tab at the start): ranlib ../lib/$@ Also delete the precompiled Windows lib in laslib/lib. You should be able to use the library right from the source, it's static so it will be built into GRASS without needing a copy of the laslib. For GRASS configuration, the library will be in that lib folder and includes in the laslib/inc folder. On Aug 24, 2015, at 3:47 PM, Michael Barton michael.bar...@asu.edu wrote: For LASlib compliing, I managed to get past the GEOTIFF problem with the following: cmake -G Unix Makefiles -D CMAKE_OSX_ARCHITECTURES=i386;x86_64” \ -D CMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.7.sdk” \ -D GDAL_CONFIG=/Library/Frameworks/GDAL.framework/Programs/gdal-config \ -D GEOTIFF_INCLUDE_DIR=/Library/Frameworks/UnixImageIO.framework/unix/include \ -D GEOTIFF_LIBRARY=/Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib \ ../ But now cmake is complaining about the CMAKE_OSX_ARCHITECTURES flag. I don’t know if this harkens back to the similar problem with boost or if this is new. I’ve tried both i386 and x86_64 individually and it still won’t compile. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Aug 24, 2015, at 1:30 PM, Michael Barton michael.bar...@asu.edu wrote: I’ve started trying to recompile liblas using the notes from last time (I think William provided considerable help on this). So far it is not working. 1 Recompiling boost 1.5.4 cd /Users/Shared/grass_dev/boost_1_54_0 ##note that I did not do anything to clean up my original compilation. Should I? How with C++? edit /Users/Shared/grass_dev/boost_1_54_0/tools/build/v2/tools/darwin.jam to delete -gdwarf-2 ## already done export CXXFLAGS=-stdlib=libstdc++ ./bootstrap.sh --prefix=/Users/cmbarton/Dropbox/GRASS_dropbox/compiling/boost-snow --without-libraries=python ## this worked several years ago but now fails. I DO have the OS X 10.7 SDK FWIW ./bjam variant=release link=static --without-mpi -j4 macosx-version=10.7 macosx-version-min=10.7 architecture=x86 address-model=32_64 install ## So I tried without specifying the minimum OS and address model. This compiled but could be incorrect ./bjam variant=release link=static --without-mpi -j4 install ## This was in my notes but does not seem needed Need to manually delete the comma at the end of the list on line 117 of /boost-snow/include/boost/interprocess/errors.hpp 3. Then follow instructions at: http://www.liblas.org/compilation.html#using-xcode-on-os-x for standard install (not xcode) from libLAS folder... cd to liblas source folder mkdir makefiles cd makefiles export BOOST_ROOT=/Users/cmbarton/Dropbox/GRASS_dropbox/compiling/boost-snow cmake -G Unix Makefiles -D CMAKE_OSX_ARCHITECTURES=i386;x86_64 -D CMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.7.sdk ../ ## fails because it can’t find geotiff libraries. But it does find geotiff libraries. So that’s weird. Also cannot find laszip. I can’t tell if this is required or optional. I didn’t need it before. ## here is the error… Searching for LASzip 2.0.1+ library -- Could
Re: [GRASS-dev] New Mac binaries uploaded
Michael, you may need to recompile your las tools to use the current GDAL, this is separate from GRASS compilation. On Aug 24, 2015, at 10:31 AM, Michael Barton michael.bar...@asu.edu wrote: Anna, These work for me and at least some of my students here. So we need to find out why they don't work for you. I'm teaching spatial tech this fall and want to make sure others don't run into trouble. 7.0.1 was a completely fresh checkout and 7.1 was compiled after a make distclean. Do you have any idea what causes this error? Did you install a new gdal? I compiled with William's most current version. I am still using stock Mac Python and wx version 2.8.12. Have you installed anything newer in the testing I saw on the list? Michael Barton School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University ...Sent from my iPad On Aug 24, 2015, at 7:43 AM, Anna Petrášová kratocha...@gmail.com wrote: Hi Michael, sorry to report but the new binaries (70 and 71) don't work, the gui doesn't open with this error. I already saw this error multiple times and it might be enough just to make distclean and recompile or fresh svn checkout. GRASS 7.1.svn (loc_ncarolina_spm_base0.3.1):~ Traceback (most recent call last): File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 140, in module sys.exit(main()) File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 132, in main app = GMApp(workspaceFile) File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 46, in __init__ wx.App.__init__(self, False) File /Applications/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7981, in __init__ self._BootstrapApp() File /Applications/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 79, in OnInit from lmgr.frame import GMFrame File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/frame.py, line 50, in module from lmgr.layertreeimport LayerTree, LMIcons File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py, line 37, in module from mapdisp.frameimport MapFrame File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py, line 34, in module from vdigit.toolbarsimport VDigitToolbar File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py, line 30, in module from iclass.digit import IClassVDigit File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/iclass/digit.py, line 23, in module from vdigit.wxdisplay import DisplayDriver, TYPE_AREA ImportError: cannot import name TYPE_AREA Also, v.in.lidar or las2las (anything using liblas) doesn't work. I don't have GDAL 1.10, but 1.11. dyld: Library not loaded: /Library/Frameworks/GDAL.framework/Versions/1.10/GDAL Referenced from: /Applications/GRASS-7.1.app/Contents/MacOS/lib/liblas.2.2.0.dylib Reason: image not found Trace/BPT trap: 5 If you don't have time to look at it now, could you please post the GRASS 7.0.0 binary which I believe worked. Thank you, Anna - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New Mac binaries uploaded
: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Aug 24, 2015, at 10:50 AM, Vaclav Petras wenzesl...@gmail.com wrote: On Mon, Aug 24, 2015 at 1:40 PM, Michael Barton michael.bar...@asu.edu wrote: If I am understanding the compiling instructions correctly, it installs binaries of the open source LAStools and Liblas too. But I may misunderstand. The GRASS LAS tool set needs both I believe. GRASS GIS is fine just with the library. The expected library libLAS (http://www.liblas.org/) as far as I know. I'm not sure what open source LAStools would be, some of the LAStools are perhaps open source but some are definitively not. In any case, GRASS GIS does not depend on any tools -- the ones related to libLAS nor the ones related LASlib. Vaclav Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Aug 24, 2015, at 10:29 AM, Newcomb, Doug doug_newc...@fws.gov wrote: Liblas or LASTools? Doug On Mon, Aug 24, 2015 at 1:08 PM, Michael Barton michael.bar...@asu.edu wrote: Yes. The LAS tools are compiled for GDAL 1.10. They were a royal pain to compile. The instructions to the newest LAStools source code makes it sound like it is much easier now. Does anyone have any experience with the current version? I was going to try it but wanted to make sure I had a GRASS version out with at least a clunky working version before risking it. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Aug 24, 2015, at 9:56 AM, William Kyngesburye wokl...@kyngchaos.com wrote: Michael, you may need to recompile your las tools to use the current GDAL, this is separate from GRASS compilation. On Aug 24, 2015, at 10:31 AM, Michael Barton michael.bar...@asu.edu wrote: Anna, These work for me and at least some of my students here. So we need to find out why they don't work for you. I'm teaching spatial tech this fall and want to make sure others don't run into trouble. 7.0.1 was a completely fresh checkout and 7.1 was compiled after a make distclean. Do you have any idea what causes this error? Did you install a new gdal? I compiled with William's most current version. I am still using stock Mac Python and wx version 2.8.12. Have you installed anything newer in the testing I saw on the list? Michael Barton School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University ...Sent from my iPad On Aug 24, 2015, at 7:43 AM, Anna Petrášová kratocha...@gmail.com wrote: Hi Michael, sorry to report but the new binaries (70 and 71) don't work, the gui doesn't open with this error. I already saw this error multiple times and it might be enough just to make distclean and recompile or fresh svn checkout. GRASS 7.1.svn (loc_ncarolina_spm_base0.3.1):~ Traceback (most recent call last): File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 140, in module sys.exit(main()) File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 132, in main app = GMApp(workspaceFile) File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 46, in __init__ wx.App.__init__(self, False) File /Applications/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7981, in __init__ self._BootstrapApp() File /Applications/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 79, in OnInit from lmgr.frame import GMFrame File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/frame.py, line 50, in module from lmgr.layertreeimport LayerTree, LMIcons File /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py, line 37, in module from mapdisp.frameimport
Re: [GRASS-dev] compiling on OSX 10.11 (El Capitan Beta)
I believe what happens is it compiles with links to where it will be installed, but during documentation creation it uses DYLD_LIBRARY_PATH to make it look in the build dir. This is what is not working. On Jul 23, 2015, at 7:40 PM, Carlos Grohmann carlos.grohm...@gmail.com wrote: On thing that I found weird id this: dyld: Library not loaded: /Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1RC2.dylib Referenced from: /Users/guano/Documents/installs/release_20150720_grass_7_0_1RC2/dist.x86_64-apple-darwin15.0.0/bin/g.parser Reason: image not found Why load the library from /Applications/GRASS-7.0.app/ at compiling time? The package hasn't even been created yet... Shouldn't this be loaded from the source dir? Carlos On Thu, Jul 23, 2015 at 12:09 AM, William Kyngesburye wokl...@kyngchaos.com wrote: I don't see any GDAL problem there. It looks like DYLD_LIBRARY_PATH is not working when running the modules to create documentation. I don't know where to go from there. On Jul 22, 2015, at 8:18 PM, Carlos Grohmann carlos.grohm...@gmail.com wrote: Thanks, William. That worked, at least for the configure part. Now the problem is at compiling. At the end of make, I get a ton of errors in modules: the first script, d.correlate, gives me this eror: cd scripts/d.correlate/ GuanoAFBIOTA:d.correlate guano$ make if [ /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/d.correlate != ] ; then GISRC=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/demolocation/.grassrc70 GISBASE=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0 PATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts:$PATH PYTHONPATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/etc/python:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/gui/wxpython:$PYTHONPATH DYLD_LIBRARY_PATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts:/Users/guano/Do cuments/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/lib:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/lib: LC_ALL=C /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/d.correlate --html-description /dev/null | grep -v '/body\|/html' d.correlate.tmp.html ; fi dyld: Library not loaded: /Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1svn.dylib Referenced from: /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin/g.parser Reason: image not found make: *** [d.correlate.tmp.html] Error 1 rm d.correlate.tmp.html - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling on OSX 10.11 (El Capitan Beta)
for location of regex library...
checking for regcomp... yes
checking whether to use Readline... no
checking whether to use GDAL... yes
checking for gdal-config...
/Library/Frameworks/GDAL.framework/Programs/gdal-config
configure: error: *** Unable to locate GDAL library.
This is the last part of config.log:
configure:6036: checking whether to use GDAL
configure:6054: checking for gdal-config
configure:6116: gcc -o conftest -Os -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/
-I/Library/Frameworks/GDAL.framework/Versions/1.11/Headers-arch x86_64
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/
conftest.c -framework GDAL 15
configure:6112:1: warning: ignoring return value of function declared with
warn_unused_result attribute [-Wunused-result]
GDALOpen(foo, GA_ReadOnly);
^~~~ ~~
1 warning generated.
ld: framework not found GDAL
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
configure: failed program was:
#line 6109 configure
#include confdefs.h
#include gdal.h
int main() {
GDALOpen(foo, GA_ReadOnly);
; return 0; }
configure:6132: gcc -o conftest -Os -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/
-I/Library/Frameworks/GDAL.framework/Versions/1.11/Headers-arch x86_64
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/
conftest.c -framework GDAL 15
configure:6128:1: warning: ignoring return value of function declared with
warn_unused_result attribute [-Wunused-result]
GDALOpen(foo, GA_ReadOnly);
^~~~ ~~
1 warning generated.
ld: framework not found GDAL
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
configure: failed program was:
#line 6125 configure
#include confdefs.h
#include gdal.h
int main() {
GDALOpen(foo, GA_ReadOnly);
; return 0; }
looking for gdal-config:
which gdal-config
/Library/Frameworks/GDAL.framework/Programs/gdal-config
and for gdal.h:
locate gdal.h
/Applications/GRASS-6.4.app/Contents/MacOS/docs/html/r.in.gdal.html
/Applications/GRASS-6.4.app/Contents/MacOS/docs/html/r.out.gdal.html
/Applications/GRASS-7.0.app/Contents/MacOS/docs/html/r.in.gdal.html
/Applications/GRASS-7.0.app/Contents/MacOS/docs/html/r.out.gdal.html
/Applications/QGIS.app/Contents/MacOS/grass/docs/html/r.in.gdal.html
/Applications/QGIS.app/Contents/MacOS/grass/docs/html/r.out.gdal.html
/Library/Frameworks/GDAL.framework/Versions/1.10/Headers/gdal.h
/Library/Frameworks/GDAL.framework/Versions/1.10/Resources/doc/gdal/java/org/gdal/gdal/gdal.html
/Library/Frameworks/GDAL.framework/Versions/1.11/Headers/gdal.h
/Library/Frameworks/GDAL.framework/Versions/1.11/Resources/doc/gdal/java/org/gdal/gdal/gdal.html
So it looks to me that configure is looking at the right place for gdal.h...
any ideas?
thanks
Carlos
--
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing -
http://carlosgrohmann.com
http://orcid.org/-0001-5073-5572
Can’t stop the signal.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
-
William Kyngesburye kyngchaos*at*kyngchaos*dot*com
http://www.kyngchaos.com/
We are at war with them. Neither in hatred nor revenge and with no particular
pleasure I shall kill every ___ I can until the war is over. That is my duty.
Don't you even hate 'em?
What good would it do if I did? If all the many millions of people of the
allied nations devoted an entire year exclusively to hating the it
wouldn't kill one ___ nor shorten the war one day.
Ha, ha And it might give 'em all stomach ulcers.
- Tarzan, on war
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling on OSX 10.11 (El Capitan Beta)
-darwin15.0.0/gui/wxpython:$PYTHONPATH DYLD_LIBRARY_PATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/lib:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/lib: LC_ALL=C /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/d.correlate --html-description /dev/null | grep -v '/body\|/html' d.correlate.tmp.html ; fi dyld: Library not loaded: /Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1svn.dylib Referenced from: /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin/g.parser Reason: image not found make: *** [d.correlate.tmp.html] Error 1 rm d.correlate.tmp.html the first temporal module, t.create, this one (just last part of output): Traceback (most recent call last): File /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/t.vect.univar, line 66, in module import grass.temporal as tgis File /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/etc/python/grass/temporal/__init__.py, line 1, in module from core import * File /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/etc/python/grass/temporal/core.py, line 38, in module from c_libraries_interface import * File /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/etc/python/grass/temporal/c_libraries_interface.py, line 19, in module import grass.lib.gis as libgis File /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/etc/python/grass/lib/gis.py, line 23, in module _libs[grass_gis.7.0.1svn] = load_library(grass_gis.7.0.1svn) File /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/etc/python/grass/lib/ctypes_loader.py, line 57, in load_library raise ImportError,%s not found. % libname ImportError: grass_gis.7.0.1svn not found. make[1]: *** [t.vect.univar.tmp.html] Error 1 rm t.vect.univar.tmp.html The gui modules also give an error similar to d.correlate, so something is referencing grass_gis.7.0.1svn instead of the current release. thanks Carlos -- Prof. Carlos Henrique Grohmann Institute of Energy and Environment - Univ. of São Paulo, Brazil - Digital Terrain Analysis | GIS | Remote Sensing - http://carlosgrohmann.com http://orcid.org/-0001-5073-5572 Can’t stop the signal. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PROJ problem compiling GRASS trunk
Oops, the PROJ programs are still linked to my build. I'll fix it soon. On May 18, 2015, at 2:51 PM, Michael Barton michael.bar...@asu.edu wrote: I just updated and tried to compile GRASS trunk. I also updated to the 2015-04-11 version of GDAL complete 1.11 When I tried compiling, I got the following error from /Users/cmbarton/grass_source/grass_trunk/lib/proj urce/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/src/stlrnc.lla /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/src/stpaul.lla /Library/Frameworks/PROJ.framework/Programs/nad2bin FL.lla /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL dyld: Library not loaded: /Users/Shared/src/proj.4/build-4.9.1/lion/usr/lib/libproj.9.dylib Referenced from: /Library/Frameworks/PROJ.framework/Programs/nad2bin Reason: image not found /bin/sh: line 1: 65178 Trace/BPT trap: 5 /Library/Frameworks/PROJ.framework/Programs/nad2bin /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL FL.lla make[1]: *** [/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL] Error 133 When I rolled back to the 2014-12 version of GDAL complete 1.11, it compiles fine. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] why java SE runtime is needed to run GRASS in Mac?
___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxpython 3 and errors in grass
There is a GRASS_WXBUNDLED var (set in the OS X grass.sh) that globalvar.py checks for, to avoid the CheckForWx() call, and it's wxversion stuff. I think the problem was that the bundled wxpython would be ignored, even though it was before another installed wxpython in the search path, something to do with the wxversion mechanism for selecting a version. On Oct 30, 2014, at 5:20 PM, Michael Barton michael.bar...@asu.edu wrote: Maybe William has this built into his bundling code. When I compile and then create a Mac binary, I specify which wx I am using by pointing to a specific wx_config. We then bundle all wxPython code into the binary *.app and GRASS uses that, whatever wx is on the user’s system. Perhaps you can’t do something similar in Linux. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University Tempe, AZ 85287-2402 USA voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Oct 30, 2014, at 3:14 PM, Glynn Clements gl...@gclements.plus.com wrote: Michael Barton wrote: At least for me, it is possible to have multiple versions of wx installed. The important thing is which you use when you compile GRASS�determined by the path to wx_config The only module which is affected by wx-config is visualisation/wximgview (which has probably been superseded by scripts/wxpyimgview). Anything written in Python will use the wxPython version found by the Python import mechanism and the wxversion module. If the code doesn't use wxversion, it will use whichever version site-packages/wx.pth refers to. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] [cmbarton.wikidot.com] Contact via Wikidot.com
GRASS needs to be compiled with Postgres support to be able to store attribute data in Postgres. Last I checked it doesn't handle Postgis directly, it's an import and uses GDAL, so it doesn't need Postgres support for that. On May 23, 2014, at 4:17 AM, Michael Barton c.michael.bar...@gmail.com wrote: I can definitely say yes to all except PG. If I have a chance, I'll try to install William's PGIS over the next few weeks and let you know. Michael Barton On May 23, 2014, at 10:22 AM, John Payne jcpa...@uw.edu wrote: I set the path in .bash_profile set as you suggested (export GRASS_PYTHON=/usr/bin/pythonw2.7), and that did the trick--Grass 7 is now running on my Mac with OS X 10.8.5. Thank you all VERY much for your help. For the future, I would love to know whether it is possible to install the following combination in Mavericks, using the KyngChaos builds: --PostgreSQL with PostGIS (postGIS is critical to me) --GRASS 7 --QGIS Thanks again, John On Fri, May 23, 2014 at 2:32 AM, William Kyngesburye wokl...@kyngchaos.com wrote: Sounds like the Macports python is loading the system python global site-packages (/Library/Python). Bad form really, because you can't expect modules to work between different builds of python, even if they're the same version. Maybe there is some option in Macports python to exclude the system site-packages. To get GRASS to always use the system python, just set GRASS_PYTHON (you can set this in your .bash_profile): export GRASS_PYTHON=/usr/bin/pythonw2.7 The version is important because of the way GRASS forces 32bit. On May 22, 2014, at 10:28 AM, Adam Dershowitz adershow...@exponent.com wrote: In my case, the problem was that I had uninstalled NumPy (from kyngchaos GDAL). It was causing a conflict with Macports scipy stuff. The macports version is installed as universal but apparently is actually just 64 bit! So the workaround I have at the moment is to install NumPy when I need to use GRASS 7, and then uninstall so I can use macports python (which I need for other libraries and such). This seems like a inconvenient fix for now. Is there any way to set some paths so that they can both co-exist and GRASS will find the correct one? -- Adam On 5/22/14, 10:12 AM, Adam Dershowitz adershow...@exponent.com wrote: Just to add a bit more data. I have a 10.9 machine and also use macports, so have macports python 2.7 installed. The Kyngchaos 6.4 seems to run just fine. But, I recently tried Grass 7.0.beta2 (Barton) and I have also run into python errors. If I just try to run it I get this error: ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt h on2.7/site-packages/numpy/core/multiarray.so, 2): no suitable image found. Did find: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 / site-packages/numpy/core/multiarray.so: mach-o, but wrong architecture So, I tried switching to System python: sudo port select python python27-apple But, oddly, got the same error. So, it seems to still be using Macports numpy. But, then I tried setting: setenv GRASS_PYTHON /usr/bin/pythonw And now I get a different error: GRASS 7.0.0svn (KDEN):~ g.gui Launching wxpython GUI in the background, please wait... Traceback (most recent call last): File /Applications/Grass/GRASS-7.0.app/Contents/MacOS/gui/wxpython/wxgui.py, line 25, in module from core import globalvar File /Applications/Grass/GRASS-7.0.app/Contents/MacOS/gui/wxpython/core/global v ar.py, line 84, in module import wx File /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/__init__.p y , line 45, in module from wx._core import * File /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py, line 4, in module import _core_ ImportError: /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core_.so: no appropriate 64-bit architecture (see man python for running in 32-bit mode) But, now it is trying to use the library included with Grass, but still isn't working. -- Adam On 5/22/14, 9:27 AM, William Kyngesburye wokl...@kyngchaos.com wrote: The way the GRASS-Mac startup is configured, it looks for python in this order: what's set in GRASS_PYTHON (full path to pythonw, needed for wxpython GUI) what is found in the PATH (/opt is probably in your PATH) the python.org Python (/Library/Frameworks) the system python It checks each for the python version needed, but not the architecture. the error you are getting is probably because GRASS needs to run python 32bit because of Wxpython limitations, but the /opt python is 64bit only. That's odd that macports does that since you need wxpython 3 to be able to run 64bit. But GRASS should have its own wxpython
Re: [GRASS-dev] [cmbarton.wikidot.com] Contact via Wikidot.com
___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] [cmbarton.wikidot.com] Contact via Wikidot.com
Sounds like the Macports python is loading the system python global site-packages (/Library/Python). Bad form really, because you can't expect modules to work between different builds of python, even if they're the same version. Maybe there is some option in Macports python to exclude the system site-packages. To get GRASS to always use the system python, just set GRASS_PYTHON (you can set this in your .bash_profile): export GRASS_PYTHON=/usr/bin/pythonw2.7 The version is important because of the way GRASS forces 32bit. On May 22, 2014, at 10:28 AM, Adam Dershowitz adershow...@exponent.com wrote: In my case, the problem was that I had uninstalled NumPy (from kyngchaos GDAL). It was causing a conflict with Macports scipy stuff. The macports version is installed as universal but apparently is actually just 64 bit! So the workaround I have at the moment is to install NumPy when I need to use GRASS 7, and then uninstall so I can use macports python (which I need for other libraries and such). This seems like a inconvenient fix for now. Is there any way to set some paths so that they can both co-exist and GRASS will find the correct one? -- Adam On 5/22/14, 10:12 AM, Adam Dershowitz adershow...@exponent.com wrote: Just to add a bit more data. I have a 10.9 machine and also use macports, so have macports python 2.7 installed. The Kyngchaos 6.4 seems to run just fine. But, I recently tried Grass 7.0.beta2 (Barton) and I have also run into python errors. If I just try to run it I get this error: ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyt h on2.7/site-packages/numpy/core/multiarray.so, 2): no suitable image found. Did find: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 / site-packages/numpy/core/multiarray.so: mach-o, but wrong architecture So, I tried switching to System python: sudo port select python python27-apple But, oddly, got the same error. So, it seems to still be using Macports numpy. But, then I tried setting: setenv GRASS_PYTHON /usr/bin/pythonw And now I get a different error: GRASS 7.0.0svn (KDEN):~ g.gui Launching wxpython GUI in the background, please wait... Traceback (most recent call last): File /Applications/Grass/GRASS-7.0.app/Contents/MacOS/gui/wxpython/wxgui.py, line 25, in module from core import globalvar File /Applications/Grass/GRASS-7.0.app/Contents/MacOS/gui/wxpython/core/global v ar.py, line 84, in module import wx File /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/__init__.p y , line 45, in module from wx._core import * File /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py, line 4, in module import _core_ ImportError: /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core_.so: no appropriate 64-bit architecture (see man python for running in 32-bit mode) But, now it is trying to use the library included with Grass, but still isn't working. -- Adam On 5/22/14, 9:27 AM, William Kyngesburye wokl...@kyngchaos.com wrote: The way the GRASS-Mac startup is configured, it looks for python in this order: what's set in GRASS_PYTHON (full path to pythonw, needed for wxpython GUI) what is found in the PATH (/opt is probably in your PATH) the python.org Python (/Library/Frameworks) the system python It checks each for the python version needed, but not the architecture. the error you are getting is probably because GRASS needs to run python 32bit because of Wxpython limitations, but the /opt python is 64bit only. That's odd that macports does that since you need wxpython 3 to be able to run 64bit. But GRASS should have its own wxpython bundled, and it's best to use the python it was compiled for (system python as Michael said). On May 22, 2014, at 4:31 AM, Michael Barton c.michael.bar...@gmail.com wrote: I haven't installed PostGIS, so you'll have to ask William about that. But I do have Mavericks, GRASS 6 and 7, and QGIS v. 2 working together. I don't know how to best set the environment to use the system python. It is best to ask the list if someone has done this (copied here). OS X is a version of Unix, which is similar but not identical to Linux. Many of the configuration files for setting environmental variables are similar between OS X and Linux, but they can vary sometimes. Michael Barton On May 22, 2014, at 5:32 AM, John Payne jpa...@wcs.org wrote: Hi Michael, Thank you -- I remember reading about conflicts between multiple Python versions but I don't know how to tell whether the /opt version is being used by other software so I'm hesitant to remove it. I haven't switched to Mavericks yet for fear that it would break things, but perhaps it's time to take the plunge. It looks to me as though you and William Kyngesbury have made it possible
Re: [GRASS-dev] [SPAM?] Re: [GRASS-user] GRASS GIS 7.0.0beta1 is out
ls -l in a terminal
chmod +x to fix
On Apr 7, 2014, at 4:42 PM, Michael Barton michael.bar...@asu.edu wrote:
How would that happen? What do I check?
Michael
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ 85287-2402
USA
voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton
On Apr 7, 2014, at 2:36 PM, William Kyngesburye wokl...@kyngchaos.com wrote:
Is your postflight script executable? Maybe it was made non-executable
accidentally.
On Apr 7, 2014, at 4:28 PM, Michael Barton michael.bar...@asu.edu wrote:
Hmmm.
On further investigation, this may be a bogus error. In spite of the error,
GRASS does seem to install and seems to run OK.
Below is the relevant part of the installer log. I wonder if this is a
function of using an old PackageMaker?
Michael
= installer log error ===
Apr 7 14:22:04 anthgradpc7.la.asu.edu installd[405]: PackageKit: Adding
client PKInstallDaemonClient pid=43626, uid=501
(/System/Library/CoreServices/Installer.app/Contents/MacOS/Installer)
Apr 7 14:22:04 anthgradpc7.la.asu.edu Installer[43626]: PackageKit:
Enqueuing install with boosting
Apr 7 14:22:04 anthgradpc7.la.asu.edu installd[405]: PackageKit: -
Begin install -
Apr 7 14:22:04 anthgradpc7.la.asu.edu installd[405]: PackageKit:
request=PKInstallRequest 1 packages, destination=/
Apr 7 14:22:04 anthgradpc7.la.asu.edu installd[405]: PackageKit: packages=(
PKJaguarPackage
file://localhost/Users/cmbarton/Downloads/GRASS-7.0beta1-3.pkg
)
Apr 7 14:22:04 anthgradpc7.la.asu.edu installd[405]: PackageKit: Will do
receipt-based obsoleting for package identifier org.osgeo.grass7_0 (prefix
path=Applications/GRASS)
Apr 7 14:22:04 anthgradpc7.la.asu.edu installd[405]: PackageKit:
Extracting file://localhost/Users/cmbarton/Downloads/GRASS-7.0beta1-3.pkg
(destination=/var/folders/zz/zyxvpxvq6csfxvn_n0/C/PKInstallSandboxManager/1A686F86-EDBD-4B0C-A4E0-74F6A82C7C7B.activeSandbox/Root/Applications/GRASS,
uid=0)
Apr 7 14:22:58 anthgradpc7.la.asu.edu installd[405]: PackageKit: prevent
user idle system sleep
Apr 7 14:22:58 anthgradpc7.la.asu.edu installd[405]: PackageKit:
suspending backupd
Apr 7 14:22:58 anthgradpc7.la.asu.edu install_monitor[43659]: Temporarily
excluding: /Applications, /Developer, /Library, /System, /bin, /private,
/sbin, /usr
Apr 7 14:22:58 anthgradpc7.la.asu.edu installd[405]: PackageKit: Using
trashcan path
/var/folders/zz/zyxvpxvq6csfxvn_n0/T/PKInstallSandboxTrash/1A686F86-EDBD-4B0C-A4E0-74F6A82C7C7B.sandboxTrash
for sandbox
/var/folders/zz/zyxvpxvq6csfxvn_n0/C/PKInstallSandboxManager/1A686F86-EDBD-4B0C-A4E0-74F6A82C7C7B.activeSandbox
Apr 7 14:22:58 anthgradpc7.la.asu.edu installd[405]: PackageKit: Shoving
/var/folders/zz/zyxvpxvq6csfxvn_n0/C/PKInstallSandboxManager/1A686F86-EDBD-4B0C-A4E0-74F6A82C7C7B.activeSandbox/Root
(1 items) to /
Apr 7 14:22:58 anthgradpc7.la.asu.edu installd[405]: PackageKit: Executing
script ./postflight in
/Users/cmbarton/Downloads/GRASS-7.0beta1-3.pkg/Contents/Resources
Apr 7 14:22:58 anthgradpc7.la.asu.edu installd[405]: PackageKit: ***
launch path not accessible
Apr 7 14:22:59 anthgradpc7.la.asu.edu install_monitor[43659]: Re-included:
/Applications, /Developer, /Library, /System, /bin, /private, /sbin, /usr
Apr 7 14:22:59 anthgradpc7.la.asu.edu installd[405]: PackageKit: releasing
backupd
Apr 7 14:22:59 anthgradpc7.la.asu.edu installd[405]: PackageKit: allow
user idle system sleep
Apr 7 14:22:59 anthgradpc7.la.asu.edu installd[405]: PackageKit: Install
Failed: Error Domain=PKInstallErrorDomain Code=112 An error occurred while
running scripts from the package “GRASS-7.0beta1-3.pkg”.
UserInfo=0x7f967766efa0 {NSFilePath=./postflight,
NSURL=file://localhost/Users/cmbarton/Downloads/GRASS-7.0beta1-3.pkg,
PKInstallPackageIdentifier=org.osgeo.grass7_0, NSLocalizedDescription=An
error occurred while running scripts from the package
“GRASS-7.0beta1-3.pkg”.} {
NSFilePath = ./postflight;
NSLocalizedDescription = An error occurred while running scripts
from the package \U201cGRASS-7.0beta1-3.pkg\U201d.;
NSURL =
file://localhost/Users/cmbarton/Downloads/GRASS-7.0beta1-3.pkg;
PKInstallPackageIdentifier = org.osgeo.grass7_0;
}
Apr 7 14:22:59 anthgradpc7.la.asu.edu installd[405]: PackageKit: Running
idle tasks
Apr 7 14:22:59 anthgradpc7.la.asu.edu installd[405]: PackageKit: Done with
sandbox removals
Apr 7 14:22:59 anthgradpc7.la.asu.edu
Re: [GRASS-dev] [GRASS-user] GRASS GIS 7.0.0beta1 is out
]: PackageKit: allow user
idle system sleep
Apr 7 09:40:27 adershowitzMBP15 installd[48393]: PackageKit: Install
Failed: Error Domain=PKInstallErrorDomain Code=112 An error occurred
while running scripts from the package ³GRASS-7.0beta1.pkg².
UserInfo=0x7fcf8b60a540 {NSFilePath=./postflight,
NSURL=file://localhost/Users/adershowitz/Downloads/Navigate%20etc/GRASS-7
.0
beta1.pkg, PKInstallPackageIdentifier=org.osgeo.grass7_0,
NSLocalizedDescription=An error occurred while running scripts from the
package ³GRASS-7.0beta1.pkg².} {
NSFilePath = ./postflight;
NSLocalizedDescription = An error occurred while running scripts
from the package \U201cGRASS-7.0beta1.pkg\U201d.;
NSURL =
file://localhost/Users/adershowitz/Downloads/Navigate%20etc/GRASS-7.0bet
a1
.pkg;
PKInstallPackageIdentifier = org.osgeo.grass7_0;
}
Apr 7 09:40:27 adershowitzMBP15 Installer[57796]:
install:didFailWithError:Error Domain=PKInstallErrorDomain Code=112 An
error occurred while running scripts from the package
³GRASS-7.0beta1.pkg². UserInfo=0x610eb400 {NSFilePath=./postflight,
NSURL=file://localhost/Users/adershowitz/Downloads/Navigate%20etc/GRASS-7
.0
beta1.pkg, PKInstallPackageIdentifier=org.osgeo.grass7_0,
NSLocalizedDescription=An error occurred while running scripts from the
package ³GRASS-7.0beta1.pkg².}
Apr 7 09:40:27 adershowitzMBP15 installd[48393]: PackageKit: Running
idle
tasks
Apr 7 09:40:27 adershowitzMBP15 installd[48393]: PackageKit: Removing
client PKInstallDaemonClient pid=57796, uid=1224806835
(/System/Library/CoreServices/Installer.app/Contents/MacOS/Installer)
Apr 7 09:40:27 adershowitzMBP15 installd[48393]: PackageKit: Done with
sandbox removals
Apr 7 09:40:27 adershowitzMBP15 Installer[57796]: Install failed: The
Installer encountered an error that caused the installation to fail.
Contact the software manufacturer for assistance.
Apr 7 09:40:27 adershowitzMBP15 Installer[57796]: IFDInstallController
2E30 state = 8
Apr 7 09:40:27 adershowitzMBP15 Installer[57796]: Displaying 'Install
Failed' UI.
Apr 7 09:40:27 adershowitzMBP15 Installer[57796]: 'Install Failed' UI
displayed message:'The Installer encountered an error that caused the
installation to fail. Contact the software manufacturer for
assistance.'.
Thanks, and any thoughts or suggestions are appreciated.
-- Adam
On 4/3/14, 7:30 PM, Michael Barton michael.bar...@asu.edu wrote:
I compiled the new GRASS 7 beta1 from the current release branch and
posted it to the http://grassmac.wikidot.com web site. In order to make
this available as soon as possible, I have had to compile it without
LAS
tools and without gettext internationalization support. If you install
this,IT WILL OVERWRITE YOUR EXISTING GRASS 7 INSTALLATION unless you
move
GRASS 7 out of the /Applications/Grass folder.
Michael
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ 85287-2402
USA
voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton
On Mar 30, 2014, at 1:37 PM, Markus Neteler nete...@osgeo.org wrote:
Dear Packagers,
(pls fwd if I forgot to cc a packager)
after almost 6 years of development, a first 7.0.0beta1 is out:
http://grass.osgeo.org/grass70/source/grass-7.0.0beta1.tar.gz
http://grass.osgeo.org/grass70/source/grass-7.0.0beta1.md5sum
Could you please provide an updated installer for your distro?
(note: winGRASS standalone is already there)
I'm still completing the announcement at
http://trac.osgeo.org/grass/wiki/Release/7.0.0beta-News
and other places (feel free to improve the pages).
on behalf of all GRASS GIS users,
thanks
Markus
PS: known potential packaging issue with patch suggestion:
http://trac.osgeo.org/grass/ticket/1839
--
http://grass.osgeo.org/
http://courses.neteler.org/
http://gis.cri.fmach.it/neteler/
___
grass-user mailing list
grass-u...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
-
William Kyngesburye kyngchaos*at*kyngchaos*dot*com
http://www.kyngchaos.com/
[Trillian] What are you supposed to do WITH a maniacally depressed robot?
[Marvin] You think you have problems? What are you supposed to do if you ARE
a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more
intelligent than you and even I don't know the answer...
- HitchHiker's Guide to the Galaxy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 not finding gettext
I think you need to ignore the first error about the missing symbol for i386 - it's testing for gettext in the system library(s), not libintl, and that will fail on OS X, it's just odd that it didn't also report the error for x86_64. The next error, where it can't find libintl, is more helpful. This is testing for libintl in the system library paths. I think in the past this has included /usr/local/lib, but it appears now it does not. Maybe a change in a recent Xcode/clang update. I think there is a general lib and include flag for GRASS configure, you could try adding /usr/local/lib and /usr/local/include to that. On Apr 4, 2014, at 12:00 PM, Michael Barton michael.bar...@asu.edu wrote: So here is a test that I ran for William that suggests that there are indeed 2 architectures compiled into gettext. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton Begin forwarded message: From: Michael Barton michael.bar...@asu.edu Subject: Re: [SPAM?] Re: GRASS 7 not finding gettext Date: April 3, 2014 at 5:16:02 PM MST To: Kyngesburye William kyngch...@kyngchaos.com Cc: Markus Neteler nete...@osgeo.org The following with my old installation and the new compilations of today: /usr/local/lib/libintl.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libintl.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /usr/local/lib/libintl.dylib (for architecture i386): Mach-O dynamically linked shared library i386 Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Apr 3, 2014, at 5:11 PM, William Kyngesburye kyngch...@kyngchaos.com wrote: what doe you get with file /usr/local/lib/libintl.dylib On Apr 3, 2014, at 7:08 PM, Michael Barton michael.bar...@asu.edu wrote: Hmm. I had no problem with compiling GRASS when I last did it in February. When I just now recompiled gettext (current version), I used the same setup I did before, except that I’ve limited it to OSX 10.7 and above. export MACOSX_DEPLOYMENT_TARGET=10.7 ./configure --prefix=/usr/local --disable-dependency-tracking --disable-java --disable-libasprintf CFLAGS=-Os -arch x86_64 -arch i386 -fno-common -isysroot /Developer/SDKs/MacOSX10.7.sdk” make sudo make install == MIchael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Apr 3, 2014, at 4:48 PM, William Kyngesburye kyngch...@kyngchaos.com wrote: It looks like your gettext/libintl is missing 32bit arch. On Apr 3, 2014, at 4:16 PM, Michael Barton michael.bar...@asu.edu wrote: I don’t know what has changed, but I just recompiled gettext and redid configure. It still does not find gettext. The configure flag I’m using is --with-nls That’s still correct, right? Here is the error: checking whether to use NLS... yes checking for gettext... no checking for gettext in -lintl... no configure: error: *** Unable to locate gettext() function. Here is what seems to be the right place from configure.log ; return 0; } configure:11940: checking whether to use FreeType configure:11959: checking for location of FreeType includes configure:11985: checking for ft2build.h configure:11993: gcc -E -I/Library/Frameworks/FreeType.framework/unix/include/freetype2 -I/Library/Frameworks/FreeType.framework/unix/include conftest.c /dev/null 2conftest.out configure:12027: checking for location of FreeType library configure:12052: checking for FT_Init_FreeType in -lfreetype configure:12069: gcc -o conftest -g -O2 -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.7.sdk -L/Library/Frameworks
Re: [GRASS-dev] problem bundling GRASS 6.5 and 6.4 RB
. There was a recent change in GUI related to extensions but it's working for me. Have you updated properly? There shouldn't be any UninstallExtensionWindow now, it's renamed to ManageExtensionWindow. Anna GRASS 7.0.svn (nc_spm_08):~ Traceback (most recent call last): File /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py, line 39, in module from lmgr.frame import GMFrame File /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/lmgr/frame.py, line 68, in module from modules.extensionsimport InstallExtensionWindow, UninstallExtensionWindow ImportError: cannot import name UninstallExtensionWindow GRASS 7.0.svn (nc_spm_08):~ Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Feb 7, 2014, at 5:39 PM, William Kyngesburye wokl...@kyngchaos.com wrote: Woops. I deleted too much when I killed the modbuild stuff a few weeks ago. Should be working now. On Feb 7, 2014, at 6:19 PM, Michael Barton wrote: William, I just recompiled GRASS 7 and bundled it for distribution. It went fine. But when I went to do the same for GRASS 6.5 and 6.4 RB I ran into an odd error. Compilation went fine. No errors in either. But bundling bombed with the following error: … cp -Rf /Library/Python/2.7/site-packages/pyparsing.py /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/etc/python sed -i '' -e 's/^GRASS_WXBUNDLED=.*/GRASS_WXBUNDLED=1/' /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/grass.sh sed: /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/grass.sh: No such file or directory Is there no longer a grass.sh for GRASS 6.x? If not, what do we use to start it? The same line does not cause an error for GRASS 7. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] problem bundling GRASS 6.5 and 6.4 RB
Woops. I deleted too much when I killed the modbuild stuff a few weeks ago. Should be working now. On Feb 7, 2014, at 6:19 PM, Michael Barton wrote: William, I just recompiled GRASS 7 and bundled it for distribution. It went fine. But when I went to do the same for GRASS 6.5 and 6.4 RB I ran into an odd error. Compilation went fine. No errors in either. But bundling bombed with the following error: … cp -Rf /Library/Python/2.7/site-packages/pyparsing.py /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/etc/python sed -i '' -e 's/^GRASS_WXBUNDLED=.*/GRASS_WXBUNDLED=1/' /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/grass.sh sed: /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass64_rb/macosx/dist/GRASS-6.4.app/Contents/MacOS/grass.sh: No such file or directory Is there no longer a grass.sh for GRASS 6.x? If not, what do we use to start it? The same line does not cause an error for GRASS 7. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] ReadMe.rtf
It's purpose is to have all info about compiling GRASS on OS X - there is a lot needed on OS X that is not covered by a simple Linux configure-compile. I haven't updated it in a while because it all still mostly applies, and I've been too lazy to make minor changes for new systems (and my interest is waning). Also, it should probably be moved to the wiki page for compiling on OS X - easier for others to update and add custsom build info. On Dec 18, 2013, at 4:33 PM, Vaclav Petras wrote: Hi, what is the purpose of macosx/pkg/resources/ReadMe.rtf? I just removed note about xganim from it but I really don't know if it should be replaced by g.gui.animation or just removed. I'm not sure about the purpose of this file. The last change (not counting my) was 6 years ago (in GRASS 7), so I would say that it is outdated. There is a lot of information about X11 and Tcl/Tk and then some info about GPS, R and other things. The only unique information there are the notes about running Mac OS X app. But this might be part of some standard manual page. Is this file used for something, so we should update it and decide what information should be there, or can we just remove it? Thanks for info, Vaclav [ReadMe.rtf] http://trac.osgeo.org/grass/browser/grass/trunk/macosx/pkg/resources/ReadMe.rtf ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] ReadMe.rtf
Brain just saw the Readme part and assumed the wrong one. This one is for packaging, when you build an installer package with make bindist. It will be installed in /Users/Shared. It's an intro to get an end user started after installing a binary distribution. From there they can get to the GRASS site for documentation, mailing list help and wiki. Yes, lots of outdated stuff there, even the GRASS site link is old. And it should probably not have my contact info. On Dec 18, 2013, at 7:41 PM, Vaclav Petras wrote: On Wed, Dec 18, 2013 at 7:37 PM, William Kyngesburye wokl...@kyngchaos.com wrote: It's purpose is to have all info about compiling GRASS on OS X - there is a lot needed on OS X that is not covered by a simple Linux configure-compile. Sure makes sense for macosx/ReadMe.rtf, but I was actually asking about macosx/pkg/resources/ReadMe.rtf. https://trac.osgeo.org/grass/browser/grass/trunk/macosx/ReadMe.rtf https://trac.osgeo.org/grass/browser/grass/trunk/macosx/pkg/resources/ReadMe.rtf I haven't updated it in a while because it all still mostly applies, and I've been too lazy to make minor changes for new systems (and my interest is waning). Also, it should probably be moved to the wiki page for compiling on OS X - easier for others to update and add custsom build info. +1 for moving to wiki (GRASS wiki, wikimedia). There are interactions for linux distos (not sure about MS Windows, maybe GRASS Trac wiki?). On Dec 18, 2013, at 4:33 PM, Vaclav Petras wrote: Hi, what is the purpose of macosx/pkg/resources/ReadMe.rtf? I just removed note about xganim from it but I really don't know if it should be replaced by g.gui.animation or just removed. I'm not sure about the purpose of this file. The last change (not counting my) was 6 years ago (in GRASS 7), so I would say that it is outdated. There is a lot of information about X11 and Tcl/Tk and then some info about GPS, R and other things. The only unique information there are the notes about running Mac OS X app. But this might be part of some standard manual page. Is this file used for something, so we should update it and decide what information should be there, or can we just remove it? Thanks for info, Vaclav [ReadMe.rtf] http://trac.osgeo.org/grass/browser/grass/trunk/macosx/pkg/resources/ReadMe.rtf ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks
On Dec 7, 2013, at 12:04 PM, Michael Barton wrote: Additional good news. I grabbed a copy of the old packagemaker.app from the XCode 4 auxtools, dropped it into /Developer/Aux_tools/ (where I had it before), and it seems to work find for making a GRASS 7 package. Another casualty in Xcode. We need to figure out how to use the new packaging tools. Packagemaker was deprecated in Xcode 4 in favor of more raw tools (which are also necessary for signing): pkgbuild, productbuild and pkgutil. I found a stackoverflow question with some good info to start with, I just haven't sat down and tried anything yet. http://stackoverflow.com/questions/11487596/making-os-x-installer-packages-like-a-pro-xcode4-developer-id-mountain-lion-re Now I just need to get odbc and gettext to configure again and I'm back in business. odbc seems to be in /Library/ODBC Can I just add --with-odbc=/Library/ODBC in the configure string? /Library/ODBC is just for ODBC drivers. ODBC should still be iODBC, and --with-odbc should be enough. Unless Apple completely reorganized iODBC. Is libiodbc.dylib in /Library/ODBC? Are headers in there? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history. - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks
Maybe the headers are missing? /usr/include/iodbc*.h On Dec 7, 2013, at 3:38 PM, Michael Barton wrote: Just found libiodb* in /usr/lib Maybe just need to specify a path to it? --with-odbc worked find prevously but does not configure now. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 7, 2013, at 11:27 AM, William Kyngesburye wokl...@kyngchaos.com wrote: On Dec 7, 2013, at 12:04 PM, Michael Barton wrote: Additional good news. I grabbed a copy of the old packagemaker.app from the XCode 4 auxtools, dropped it into /Developer/Aux_tools/ (where I had it before), and it seems to work find for making a GRASS 7 package. Another casualty in Xcode. We need to figure out how to use the new packaging tools. Packagemaker was deprecated in Xcode 4 in favor of more raw tools (which are also necessary for signing): pkgbuild, productbuild and pkgutil. I found a stackoverflow question with some good info to start with, I just haven't sat down and tried anything yet. http://stackoverflow.com/questions/11487596/making-os-x-installer-packages-like-a-pro-xcode4-developer-id-mountain-lion-re Now I just need to get odbc and gettext to configure again and I'm back in business. odbc seems to be in /Library/ODBC Can I just add --with-odbc=/Library/ODBC in the configure string? /Library/ODBC is just for ODBC drivers. ODBC should still be iODBC, and --with-odbc should be enough. Unless Apple completely reorganized iODBC. Is libiodbc.dylib in /Library/ODBC? Are headers in there? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history. - Hitchhiker's Guide to the Galaxy - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Resources about compiling on Mac OS X
The macosx readme in the source is meant to be the main build instructions, but I have been lax in maintaining them. I think they are still generally good. The other in the macosx/pkg folder is just for the insaller package and has no build instructions. The wiki just looks like some random stuff, and does say that the source instructions are the place to start. On Sep 5, 2013, at 9:32 PM, Vaclav Petras wrote: My problem actually was that I don't know what is the valid documentation for compilation on Mac OS X. Is there some up-to-date document? Thanks, Vaclav Unrelated: Since there was several discussions about problems with compilation on Mac OS X, I've updated the ticket #2034 with some links and info. [1] https://trac.osgeo.org/grass/ticket/2034 - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Those people who most want to rule people are, ipso-facto, those least suited to do it. - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 g.extension on OS X
Micahel, Here is a patch for GRASS 6.4.3 source to strip out the isysroot flag, allowing g.extension to compile extensions at runtime. I've updated dev6 and trunk. Makefile.patch Description: Binary data On Aug 20, 2013, at 8:48 AM, Cline, Royce L. wrote: Running OS X 10.8.4 with Xcode 4.6.2. With GRASS 6.4.3 from kyngchaos, g.extension would work on a Mac with 10.6.8, however was failing on 10.8.4 with the following errors: In file included from catchment.c:1: global.h:1:19: error: stdio.h: No such file or directory global.h:2:20: error: stdlib.h: No such file or directory global.h:3:20: error: string.h: No such file or directory global.h:4:18: error: math.h: No such file or directory In file included from /Applications/GRASS-6.4.app/Contents/MacOS/include/grass/gis.h:651, from global.h:5, from catchment.c:1: William proposed the following solution which solved my problems for GRASS 6.4.3 on 10.8.4: Hmm, could be a sysroot problem. The sysroot flags are still in platform.make from how I compiled it (to support a minimum OS version). Extensions for a specific OS X version do not need a sysroot, and the 10.6 sdk I use doesn't even exist in recent Xcodes. Try removing the sysroot flags from include/make/platform.make in the GRASS.app package: -isysroot /Developer/SDKs/MacOSX10.6.sdk William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I was getting the same initial errors in GRASS 7 as in 6.4.3, so I made the same changes in GRASS 7 and got past the initial errors. Installing static-libintl-0.18.1.1-5 resolved an issue with a missing library. Now I am getting the following error: RASS 7.0.svn (englevale):~ g.extension extension=r.stream.basins Fetching r.stream.basins from GRASS-Addons SVN (be patient)... Compiling... basins_inputs.c: In function 'process_vector': basins_inputs.c:60: warning: assignment discards qualifiers from pointer target type basins_inputs.c: In function 'process_vector': basins_inputs.c:60: warning: assignment discards qualifiers from pointer target type ERROR: MAPSET PERMANENT - permission denied make: *** [r.stream.basins.tmp.html] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. The permission all appear to correct. It is creating .tmp and a directory in It: drwxr-xr-x 4 rcline staff 136 Aug 20 08:44 .tmp drwxr-xr-x 2 rcline staff68 Aug 20 08:37 dhcp-10-33-133-197.swc.nd.gov Anybody have an idea what would cause the permissions denied error? Royce ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS6.4.3RC3 on downloads web site
Runs on 10.8 also. Please provide details about what's happening for you. On Aug 16, 2013, at 5:22 PM, William Kyngesburye wrote: Hm, opens for me on 10.7 (essentially same as 10.8). I can try 10.8 (clean system) tomorrow. On Aug 16, 2013, at 11:59 AM, Helena Mitasova wrote: Michael, I think that you should keep what you have for GRASS6.4.3 - I just installed it on MacOSX10.8 and it at least opens correctly - I will test it more in next few days. William, your binary has similar problem as WinGRASS, it does not open the wxGUI properly - I can post more info, but Michael can probably explain what needs to be done. Helena On Thu, Aug 15, 2013 at 4:36 PM, Michael Barton michael.bar...@asu.edu wrote: Helena, Do I need to recompile GRASS 6.4.3? I don't know if I have 6.4.3-1 or not. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Aug 15, 2013, at 12:00 PM, grass-dev-requ...@lists.osgeo.org wrote: From: Helena Mitasova hmit...@ncsu.edu Subject: [GRASS-dev] GRASS6.4.3RC3 on downloads web site Date: August 14, 2013 7:13:27 PM MST To: GRASS developers grass-developers grass-dev@lists.osgeo.org I just checked the download webpage and it lists GRASS6.4.2 | 6.4.3RC3 as stable versions, but the news says that GRASS6.4.3 has been released - should the above be changed to 6.4.3 too? http://grass.osgeo.org/download/software/ WinGRASS binaries show 6.4.3-1 as the latest stable but the link at Installing GRASS points to WinGRASS6.4.2-2, should that be changed to 6.4.3-1? http://grass.osgeo.org/grass64/binary/mswindows/native/ the binaries for Mac http://grass.osgeo.org/download/software/mac-osx/ show the link to William's web page first which has 6.4.2 binaries (William, any chance for providing 6.4.3?) but Michael's web site has GRASS6.4.3 binaries - should it be listed first? We haven't tried WinGRASS6.4.3-1 yet, I am wondering whether there are any known issues besides the ones listed on wiki under WinGRASS errors Thank you, Helena Helena Mitasova Associate Professor Department of Marine, Earth, and Atmospheric Sciences 2800 Faucette Drive, Rm. 1125 Jordan Hall North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” -- Helena Mitasova Associate Professor Department of Marine, Earth and Atmospheric Sciences North Carolina State University 1125 Jordan Hall NCSU Box 8208 Raleigh, NC 27695-8208 http://skagit.meas.ncsu.edu/~helena/ email: hmit...@ncsu.edu ph: 919-513-1327 (no voicemail) fax 919 515-7802 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS6.4.3RC3 on downloads web site
Hm, opens for me on 10.7 (essentially same as 10.8). I can try 10.8 (clean system) tomorrow. On Aug 16, 2013, at 11:59 AM, Helena Mitasova wrote: Michael, I think that you should keep what you have for GRASS6.4.3 - I just installed it on MacOSX10.8 and it at least opens correctly - I will test it more in next few days. William, your binary has similar problem as WinGRASS, it does not open the wxGUI properly - I can post more info, but Michael can probably explain what needs to be done. Helena On Thu, Aug 15, 2013 at 4:36 PM, Michael Barton michael.bar...@asu.edu wrote: Helena, Do I need to recompile GRASS 6.4.3? I don't know if I have 6.4.3-1 or not. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Aug 15, 2013, at 12:00 PM, grass-dev-requ...@lists.osgeo.org wrote: From: Helena Mitasova hmit...@ncsu.edu Subject: [GRASS-dev] GRASS6.4.3RC3 on downloads web site Date: August 14, 2013 7:13:27 PM MST To: GRASS developers grass-developers grass-dev@lists.osgeo.org I just checked the download webpage and it lists GRASS6.4.2 | 6.4.3RC3 as stable versions, but the news says that GRASS6.4.3 has been released - should the above be changed to 6.4.3 too? http://grass.osgeo.org/download/software/ WinGRASS binaries show 6.4.3-1 as the latest stable but the link at Installing GRASS points to WinGRASS6.4.2-2, should that be changed to 6.4.3-1? http://grass.osgeo.org/grass64/binary/mswindows/native/ the binaries for Mac http://grass.osgeo.org/download/software/mac-osx/ show the link to William's web page first which has 6.4.2 binaries (William, any chance for providing 6.4.3?) but Michael's web site has GRASS6.4.3 binaries - should it be listed first? We haven't tried WinGRASS6.4.3-1 yet, I am wondering whether there are any known issues besides the ones listed on wiki under WinGRASS errors Thank you, Helena Helena Mitasova Associate Professor Department of Marine, Earth, and Atmospheric Sciences 2800 Faucette Drive, Rm. 1125 Jordan Hall North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” -- Helena Mitasova Associate Professor Department of Marine, Earth and Atmospheric Sciences North Carolina State University 1125 Jordan Hall NCSU Box 8208 Raleigh, NC 27695-8208 http://skagit.meas.ncsu.edu/~helena/ email: hmit...@ncsu.edu ph: 919-513-1327 (no voicemail) fax 919 515-7802 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS6.4.3RC3 on downloads web site
Ah! I thought I updated my page. It was uploaded. OK now. On Aug 14, 2013, at 9:13 PM, Helena Mitasova wrote: I just checked the download webpage and it lists GRASS6.4.2 | 6.4.3RC3 as stable versions, but the news says that GRASS6.4.3 has been released - should the above be changed to 6.4.3 too? http://grass.osgeo.org/download/software/ WinGRASS binaries show 6.4.3-1 as the latest stable but the link at Installing GRASS points to WinGRASS6.4.2-2, should that be changed to 6.4.3-1? http://grass.osgeo.org/grass64/binary/mswindows/native/ the binaries for Mac http://grass.osgeo.org/download/software/mac-osx/ show the link to William's web page first which has 6.4.2 binaries (William, any chance for providing 6.4.3?) but Michael's web site has GRASS6.4.3 binaries - should it be listed first? We haven't tried WinGRASS6.4.3-1 yet, I am wondering whether there are any known issues besides the ones listed on wiki under WinGRASS errors Thank you, Helena Helena Mitasova Associate Professor Department of Marine, Earth, and Atmospheric Sciences 2800 Faucette Drive, Rm. 1125 Jordan Hall North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Make grass 7 installable with brew on Mac?
There are easy to install OS X installer packages for everything you need for GRASS, and other GIS software. I wouldn't call package managers easier and painless on OS X, just another way to do things. The /Library problems is the linking of the help files to the system help. For the help to be available to all users, it must be /Library. I've been thinking about it off and on and have a couple ideas, I just haven't had time to work on it. I don't do homebrew or any other package manager, and I don't do ruby, so I can't help you with that error, you should ask the homebrew folks. On Jul 2, 2013, at 4:27 AM, Rainer M Krug wrote: Hi I just recently migrated to a Mac with OS X, and one think I am really missing is the package management. Therefore, I am now using homebrew [1] which works nicely - only that the recipe for installing grass from head does not work [2]. I would think that homebrew would be a nice addition to the ways of installing on OS X and it would make using GRASS much easied (all dependencies have a installation recipe, R has one as well, installation of rgdal is painless (from source)). According to adamv [3] the problem is the following: , | Looking at the source to the new version, it still tries to install | files into /Library, but it now does it in a separate OS X specific | Makefile. ` Is there any chance that somebody with a mac at hand and interest could take a look at this? It sounds like an easy to solve problem (the homebrew recipes are ruby), but I don't know anything about ruby. Thanks a lot, Rainer Footnotes: [1] http://mxcl.github.io/homebrew/ [2] error: , | patching file Makefile | Hunk #1 FAILED at 304. | 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej | Error: Failure while executing: /usr/bin/patch -f -p1 -i 000-homebrew.diff ` [3] https://github.com/mxcl/homebrew/issues/20665#issuecomment-19846487 -- Rainer M. Krug email: RMKrugatgmaildotcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 crashes on startup on Mac
I think we're probably at a point of not being able to do a single binary package for both Snow and Lion+ - too many differences. It's not quite possible to install both 2.9 carbon for Python 2.6 and 2.9 cocoa for Python 2.7 - while the python parts are separate, the C library parts of one will overwrite the other, and they are probably not compatible. The way I handle it is to compile wxpython myself. I can install each in completely separate locations and reference whichever I need for Snow or Lion builds. BUT, I haven't tried this yet for 2.9 carbon ON lion, I may have to also compile wxpython 2.9 carbon on Snow (and maybe even GRASS). On Jun 10, 2013, at 4:21 PM, Michael Barton wrote: I just installed wxPython 2.9.0.4 for Python 2.6 (for backward compatibility with Snow Leopard). It razed an error on configuration. In checking, here is what I get. /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list Default config is osx_carbon-unicode-2.9 No config found to match: /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list in /usr/local/lib/wxPython-2.9.4.0/lib/wx/config Please install the desired library build, or specify a different prefix where it may be found. If the library is not installed you may call its wx-config directly by specifying its full path. Also available in /usr/local/lib/wxPython-2.9.4.0: osx_carbon-unicode-2.9 Any idea what is wrong? MUST I use wxPython 2.9 ONLY with Python 2.7??? That means no more Snow Leopard compatibility. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Jun 7, 2013, at 8:39 PM, William Kyngesburye wokl...@kyngchaos.com wrote: I just compiled trunk, no compile errors, and GUI runs fine. OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4 I'm a bit lost now - what is the status of this, what is the current problem? On Jun 7, 2013, at 10:28 AM, Michael Barton wrote: Maybe it is PYTHONPATH BUT... Python and the GUI is compiling and working just fine otherwise. And Python runs with no problem in the terminal. The bogus errors for compiling mapswipe, composer, etc first appeared with what I think was the introduction of a new window class for these modules. I have not seen the toolbox, but it may reuse the same code. If I knew what this new code is, I might be able to troubleshoot it. But I don't have time to try to reverse engineer it without guidance as to where to look. The error on importing wx is misleading as to what the real error is. I can't say for sure that these are all related (and the error is indeed somewhat different for the toolbox compilation). But it seems a reasonable place to start. If it IS a PYTHONPATH problem, then the code for building the toolbox is somehow ignoring PYTHONPATH because this is set properly otherwise. On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton michael.bar...@asu.edu wrote: Anna, This is from the log. It looks to me like a path problem during compilation Traceback (most recent call last): File tools/build_modules_xml.py, line 85, in module sys.exit(main()) File tools/build_modules_xml.py, line 77, in main header(fh) File tools/build_modules_xml.py, line 58, in header import grass.script.core as grass ImportError: No module named grass.script.core make[1]: *** [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml] Error 1 make: [default] Error 2 (ignored) make xml/menudata.xml make[1]: `xml/menudata.xml' is up to date. make menustrings.py The other bogus errors on No module named wx also seems like a path problem. yes, problem might be in PYTHONPATH. Could you ask about this William? I have currently no time and I am probably not able to solve this. Regards, Anna On Jun 6, 2013, at 2:39 AM, Anna Petrášová kratocha...@gmail.com wrote: Hi, Michael, On Wed, Jun 5, 2013 at 11:45 PM, Michael Barton michael.bar...@asu.edu wrote: OK. I did this remotely but hopefully it is what you need. yes, perfect, thanks. Could you try the compilation again with the change William did recently (demolocation probem, [1])? It might be related because from the errors in the log it seems that the virtual grass session is not there. If the problem is still there, please send me updated compilation log. Thanks, Anna [1] https://trac.osgeo.org/grass/changeset/56621 - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com
Re: [GRASS-dev] GRASS 7 crashes on startup on Mac
I'm not sure what the status is with GRASS GUI and wxpython 2.8 vs. 2.9. I'm not sure what the status of wxpython 2.8 (carbon) is on Mt Lion. I expect things to break because of the deprecation of Carbon on Mt Lion, though existing carbon-based software should still work. I'm guessing that you can't compile wxpython, or anything else, yourself based on Carbon, so if you want to compile something that needs Carbon you must do it on Lion or Snow. It should run on Mt Lion. I do know that to get a complete 64bit-only build of GRASS 7 on any version of OS X (Snow - Mt Lion), you must use cocoa APIs, and to do that you need wxpython 2.9. On Jun 10, 2013, at 4:52 PM, Michael Barton wrote: To clarify, I was ONLY installing wxPython 2.9 carbon for Python 2.6. Other than that, I have only wxPython 2.8 for Python 2.6. On Mt. Lion, does this NOT work? If not, do I need wxPython 2.9 carbon for Python 2.7, wxPython 2.9 cocoa for Python 2.7 or will either of these 2 work? Thanks Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Jun 10, 2013, at 2:41 PM, William Kyngesburye wokl...@kyngchaos.com wrote: I think we're probably at a point of not being able to do a single binary package for both Snow and Lion+ - too many differences. It's not quite possible to install both 2.9 carbon for Python 2.6 and 2.9 cocoa for Python 2.7 - while the python parts are separate, the C library parts of one will overwrite the other, and they are probably not compatible. The way I handle it is to compile wxpython myself. I can install each in completely separate locations and reference whichever I need for Snow or Lion builds. BUT, I haven't tried this yet for 2.9 carbon ON lion, I may have to also compile wxpython 2.9 carbon on Snow (and maybe even GRASS). On Jun 10, 2013, at 4:21 PM, Michael Barton wrote: I just installed wxPython 2.9.0.4 for Python 2.6 (for backward compatibility with Snow Leopard). It razed an error on configuration. In checking, here is what I get. /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list Default config is osx_carbon-unicode-2.9 No config found to match: /usr/local/lib/wxPython-2.9.4.0/bin/wx-config --list in /usr/local/lib/wxPython-2.9.4.0/lib/wx/config Please install the desired library build, or specify a different prefix where it may be found. If the library is not installed you may call its wx-config directly by specifying its full path. Also available in /usr/local/lib/wxPython-2.9.4.0: osx_carbon-unicode-2.9 Any idea what is wrong? MUST I use wxPython 2.9 ONLY with Python 2.7??? That means no more Snow Leopard compatibility. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Jun 7, 2013, at 8:39 PM, William Kyngesburye wokl...@kyngchaos.com wrote: I just compiled trunk, no compile errors, and GUI runs fine. OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4 I'm a bit lost now - what is the status of this, what is the current problem? On Jun 7, 2013, at 10:28 AM, Michael Barton wrote: Maybe it is PYTHONPATH BUT... Python and the GUI is compiling and working just fine otherwise. And Python runs with no problem in the terminal. The bogus errors for compiling mapswipe, composer, etc first appeared with what I think was the introduction of a new window class for these modules. I have not seen the toolbox, but it may reuse the same code. If I knew what this new code is, I might be able to troubleshoot it. But I don't have time to try to reverse engineer it without guidance as to where to look. The error on importing wx is misleading as to what the real error is. I can't say for sure that these are all related (and the error is indeed somewhat different for the toolbox compilation). But it seems a reasonable place to start. If it IS a PYTHONPATH problem, then the code for building the toolbox is somehow ignoring PYTHONPATH because this is set properly otherwise. On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton michael.bar...@asu.edu wrote: Anna, This is from the log. It looks to me like a path problem during
Re: [GRASS-dev] GRASS 7 crashes on startup on Mac
I just compiled trunk, no compile errors, and GUI runs fine. OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4 I'm a bit lost now - what is the status of this, what is the current problem? On Jun 7, 2013, at 10:28 AM, Michael Barton wrote: Maybe it is PYTHONPATH BUT... Python and the GUI is compiling and working just fine otherwise. And Python runs with no problem in the terminal. The bogus errors for compiling mapswipe, composer, etc first appeared with what I think was the introduction of a new window class for these modules. I have not seen the toolbox, but it may reuse the same code. If I knew what this new code is, I might be able to troubleshoot it. But I don't have time to try to reverse engineer it without guidance as to where to look. The error on importing wx is misleading as to what the real error is. I can't say for sure that these are all related (and the error is indeed somewhat different for the toolbox compilation). But it seems a reasonable place to start. If it IS a PYTHONPATH problem, then the code for building the toolbox is somehow ignoring PYTHONPATH because this is set properly otherwise. On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton michael.bar...@asu.edu wrote: Anna, This is from the log. It looks to me like a path problem during compilation Traceback (most recent call last): File tools/build_modules_xml.py, line 85, in module sys.exit(main()) File tools/build_modules_xml.py, line 77, in main header(fh) File tools/build_modules_xml.py, line 58, in header import grass.script.core as grass ImportError: No module named grass.script.core make[1]: *** [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml] Error 1 make: [default] Error 2 (ignored) make xml/menudata.xml make[1]: `xml/menudata.xml' is up to date. make menustrings.py The other bogus errors on No module named wx also seems like a path problem. yes, problem might be in PYTHONPATH. Could you ask about this William? I have currently no time and I am probably not able to solve this. Regards, Anna On Jun 6, 2013, at 2:39 AM, Anna Petrášová kratocha...@gmail.com wrote: Hi, Michael, On Wed, Jun 5, 2013 at 11:45 PM, Michael Barton michael.bar...@asu.edu wrote: OK. I did this remotely but hopefully it is what you need. yes, perfect, thanks. Could you try the compilation again with the change William did recently (demolocation probem, [1])? It might be related because from the errors in the log it seems that the virtual grass session is not there. If the problem is still there, please send me updated compilation log. Thanks, Anna [1] https://trac.osgeo.org/grass/changeset/56621 - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
Does the GUI work with wxpython 2.8 on Mt Lion? Or on Lion? On Jun 5, 2013, at 3:11 PM, Michael Barton wrote: I agree about NOT moving to wxPython 2.9 with this release. We should do it with the next one. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jun 5, 2013, at 1:08 PM, grass-dev-requ...@lists.osgeo.org wrote: From: Martin Landa landa.mar...@gmail.com Subject: Re: [GRASS-dev] GRASS 6.4.3 release planning Date: June 5, 2013 12:43:54 PM MST To: Anna Petrášová kratocha...@gmail.com Cc: GRASS developers list grass-dev@lists.osgeo.org Hi, 2013/6/5 Anna Petrášová kratocha...@gmail.com: I think it's not good idea to apply wx2.9 patches for 6.4.3. Please bear in mind, that we have already 3 release candidates for 6.4.3 (RC1 from 10/24/2012 !!!). In this way we will never release 6.4.3... Let's move such things to 6.4.4. Let's release the software otherwise most of the user will use dev snapshots from SVN... +1 It would be time consuming to fix it, then test, fix again and so on... But of course, if we plan to release 6.4.3. in July or even later, it's enough time. I think we should have some deadline. it was discussed several times in the past. We definitely need some deadlines, otherwise we end up always in the same situation when RC covers several months (see, 6.4.0, 6.4.2, 6.4.3 history). Every RC requires some time energy (MarkusN knows it very well). Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
Ah, the make install target for OS X is a clone of the main install target, because it needs some custom handling on OS X. It probably needs to be updated to include the demolocation files. On Jun 5, 2013, at 3:37 PM, Markus Neteler wrote: On Wed, Jun 5, 2013 at 10:08 PM, Michael Barton michael.bar...@asu.edu wrote: I just was able to test g.extension on GRASS 7 compiled yesterday. I tried it with r.fuzzy because (IIRC) Markus said it is not broken and should install. Unfortunately, it does not yet work. Here is the error. Note that the demolocation is NOT my default or explicitly specified install location ($GRASS_ADDON_BASE is /Users/cmbarton/Library/GRASS/7.0/Modules). It seems that demolocation is not found? It is used in the virtual session set up during the compilation process which fails below: g.extension extension=r.fuzzy operation=add Fetching r.fuzzy from GRASS-Addons SVN (be patient)... Compiling... main.c: In function 'main': ... ERROR: LOCATION /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation not available Is it possible that the copying of demolocation to that target is not happening on Mac? It is actually needed. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
I was partly right - though the demolocation was installed, the Mac install target did not update the .grassrc70 in it. Update svn and try it now. On Jun 5, 2013, at 4:05 PM, Michael Barton wrote: It is located inside the app GRASS-7.0.app/Contents/MacOS/demolocation Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jun 5, 2013, at 1:44 PM, Markus Neteler nete...@osgeo.org wrote: On Wed, Jun 5, 2013 at 10:40 PM, Michael Barton michael.bar...@asu.edu wrote: The problem with this path... LOCATION /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation not available ...is that it assumes that the user has the source distribution. This path does not exist with a binary-only distribution. ok, then we are almost there: where is demolocation in your binary-only package? That path should be actually used. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
On May 25, 2013, at 5:31 AM, Markus Neteler wrote: #854: building addons on Mac (assume we can handle post-release in pkg'ing) --what's the situation? Commonly our Mac packagers package the release (candidate) versions, so we'll know ex-post only. I had some time to look at this, and it should be fixed now, for 6.4 at least. (Mac makefile was out of sync with the main makefile) Michael, if you're back or have dev Mac available, (and Hamish, do you have a Mac to try?) - can you verify it works for you? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
On May 25, 2013, at 2:52 PM, Anna Petrášová wrote: i was wondering if the WXgui changes in grass7, to have it running with wx2.9-cocoa can be back ported to grass6.x .. is this possible ? I haven't really thought about backporting it but yes, it's possible because the changes consist mainly of renaming (wx.Color - wx.Colour) and shifting lines (related to sizers). I would have to find relevant changesets. I would leave 6.4.3 as it is and do it after release not to break anything. Oh, I thought 6.4.3 was already fixed for wxpython 2.9 (as I try and see it fail). This is really needed to run the GRASS GUI on OS X 10.7+, especially 10.8. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] TclTk linking in GRASS 6.4
On Apr 3, 2013, at 10:13 PM, Hamish wrote: no answer for you, just fyi see also 'd.what.vect -e' and 'g.mapsets -s' for common compiled C modules calling tcl/tk forms. On Apr 4, 2013, at 6:16 AM, Glynn Clements wrote: William Kyngesburye wrote: Trying to understand the linking of TclTk in GRASS 6.4... I was poking around and noticed that libgrass_form itself does not link TclTk, and it appears it just creates form content in text and html. This content can be displayed with TclTk by the form applet, which does link TclTk, or in the console like with v.what, which does not link or use TclTk. Is this the general case then - none of the grass libraries link or use TclTk directly, just some applets (like form) and modules (like NVIZ) do? Correct. lib/form consists of the form program, a custom Tcl/Tk interpreter which adds a few commands for interfacing with the GRASS DBMI library, and a library which spawns the form program and feeds it a mixture of Tcl/Tk code and HTML. NVIZ consists of a custom Tcl/Tk interpreter which adds commands for interfacing with the OGSF library, plus a significant amount of Tcl/Tk code which uses the custom interpreter. v.digit also links against Tcl/Tk (note that it has its own embedded copy of the form library). If so, I need to rethink my OS X arch substitutions to handle 32bit-only TclTk in 64bit GRASS. In theory, it should suffice to build the two interpreters ($GISBASE/bin/nviz and $GISBASE/etc/form/form) plus v.digit as 32-bit executables. I did a test (changing the makefiles) with a 64bit d.what.vect and libform and 32bit form. Still works - 64bit d.what.vect/libform has no problem spawning a 32bit form. The main change needed then is adding a custom form.o compile target to libform makefile so that it can have separate CFLAGS from the default .o target. I hope this isn't a problem (I cut-n-paste from rules.make plus a couple changes). - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] TclTk linking in GRASS 6.4
Trying to understand the linking of TclTk in GRASS 6.4... I was poking around and noticed that libgrass_form itself does not link TclTk, and it appears it just creates form content in text and html. This content can be displayed with TclTk by the form applet, which does link TclTk, or in the console like with v.what, which does not link or use TclTk. Is this the general case then - none of the grass libraries link or use TclTk directly, just some applets (like form) and modules (like NVIZ) do? If so, I need to rethink my OS X arch substitutions to handle 32bit-only TclTk in 64bit GRASS. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] does GRASS 7 for Mac compile yet?
On Feb 5, 2013, at 7:13 AM, Nikos Alexandris wrote: Nikos Alexandris wrote: On the wxpython-problematic for OS-X: .. - python 2.7 http://python.org/ftp/python/2.7.3/python-2.7.3-macosx10.6.dmg Python 2.7 is in the Mac system starting with 10.7 (Lion). And on 10.6, the system python 2.6 works just fine. - wxpython 2.9 (the cocoa build) http://downloads.sourceforge.net/wxpython/wxPython2.9-osx-2.9.4.0-cocoa-py2.7.dmg More correctly - install wxpython 2.9 to match your python. For OS X 10.6 users, you would install wxpython 2.9 carbon py2.6. and - numpy http://garr.dl.sourceforge.net/project/numpy/NumPy/1.6.1/numpy-1.6.1-py2.7-python.org-macosx10.6.dmg Well, if you are using my GDAL framework for GRASS, it has a numpy installer in the download (and it's also available as a separate download). This is made for the system python (the official binaries are made only for the python.org python). and then set up properly GRASS to pick those up? O-kay, it seems it works :-) Configured by setting --with-wxwidgets=/usr/local/lib/wxPython-2.9.4.0/bin/wx-config, compiled, and correcting another locale-related problem (setting LC_CTYPE=en_US.UTF-8) . We can now proceed in debugging errors... :-) Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] why is r.li.setup unavailable in GRASS 7?
Hmm, everyone having these errors - is it during compilation or at runtime? I thought at first it was runtime, based on the isolated quoting of the error only, and this would make it very mysterious since the Mac compilation creates a 32bit python wrapper exactly for this problem. But Michael's error quote shows it at compilation time. this makes much more sense - this is where make runs the command to generate help, but at this point the 32bit wrapper is not made yet so the default system python runs in 64bit mode. Michael and I have workied around this by creating a dummy 32bit python wrapper before compilation and putting it in the PATH temporarily. Did you forget this Michael? I just compiled GRASS 7, with the wrapper in the PATH. no errors. So, partly a problem of documenting build process, partly a makefile problem. I've been lazy updating the Mac build readme, too much change trying to figure out weirdness like this. For this problem, I guess I was hoping we wouldn't have to deal with the 32/64bit wxPython problem for long, that wxPython devs would figure out Cocoa for 64bits sooner than they did (2.9 is still technically beta). Then you'd have a wxPython for the default system arch (64bit starting with Snow Leopard, though you'd have to install it) and make would just work, and there would be no need for a wrapper before or after compilation. I vaguely remember suggesting moving the wrapper build to the beginning of the make process, but was vetoed. On Dec 1, 2012, at 7:54 AM, Anna Kratochvílová wrote: On Sat, Dec 1, 2012 at 2:09 PM, Luca Delucchi lucadel...@gmail.com wrote: 2012/12/1 Michael Barton michael.bar...@asu.edu: Luca, Hi Micheal r.li.setup does not yet compile in GRASS 7, at least on the Mac. I'm sorry :-( Here is the error: anthgradpc7:g.version cmbarton$ cd /Users/Shared/grass_dev/grass7_dev/gui/wxpython/rlisetup anthgradpc7:rlisetup cmbarton$ make if [ /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/scripts/g.gui.rlisetup != ] ; then GISRC=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/demolocation/.grassrc70 GISBASE=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0 PATH=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/bin:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/bin:$PATH PYTHONPATH=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/etc/python:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/etc/python:$PYTHONPATH DYLD_LIBRARY_PATH=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/bin:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/lib:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/lib: LC_ALL=C /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/scripts/g.gui.rlisetup --html-description /dev/null | grep -v '/b ody\|/html' g.gui.rlisetup.tmp.html ; fi Traceback (most recent call last): File /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/scripts/g.gui.rlisetup, line 32, in module import wx File /usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/__init__.py, line 45, in module from wx._core import * File /usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core.py, line 4, in module import _core_ ImportError: /usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core_.so: no appropriate 64-bit architecture (see man python for running in 32-bit mode) make: *** [g.gui.rlisetup.tmp.html] Error 1 rm g.gui.rlisetup.tmp.html This seems more a WX problem...I know that it's a stupid answer but could you try import wx from python console? This may be the same error that is now affecting several GUI modules like map swipe, animation, and the graphical modeler. Just a remark: This problem affecting map swipe, animation, graphical modeler and r.li.setup is spread in several threads which makes it more complicated to follow. What about to choose one of them? subjects: compiling animation, mapswipe, etc. problems compiling GRASS 7 on Mac Compiling under OSX Mountain Lion Best, Anna Michael -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - 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-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling animation, mapswipe, etc.
This could happen if you configured for wxPython 2.9 64bit, but didn't bundle it so it finds the old 32bit wxPython 2.8 in the system at runtime. If you configure for wxPython 2.8 you should not get arch errors, at least if you make sure to configure 32+64bit. On Nov 29, 2012, at 11:03 PM, Helena Mitasova wrote: Just a note that when compiling trunk on MacOSX 10.6.8, running python2.6 I get Errors in: /Users/helena/grassdev7/grass_trunk/general/g.version /Users/helena/grassdev7/grass_trunk/gui/wxpython/animation /Users/helena/grassdev7/grass_trunk/gui/wxpython/mapswipe /Users/helena/grassdev7/grass_trunk/gui/wxpython/gmodeler /Users/helena/grassdev7/grass_trunk/gui/wxpython/rlisetup but mapswipe and gmodeler works anyway, unfortunately animation does not although they all show the same error (see below). Helena Traceback (most recent call last): File /Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/scripts/g.gui.animation, line 42, in module import wx File /var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/__init__.py, line 45, in module File /var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core.py, line 4, in module ImportError: /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core_.so: no appropriate 64-bit architecture (see man python for running in 32-bit mode) make: *** [g.gui.animation.tmp.html] Error 1 Traceback (most recent call last): File /Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/scripts/g.gui.mapswipe, line 40, in module import wx File /var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/__init__.py, line 45, in module File /var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core.py, line 4, in module ImportError: /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core_.so: no appropriate 64-bit architecture (see man python for running in 32-bit mode) make: *** [g.gui.mapswipe.tmp.html] Error 1 - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling animation, mapswipe, etc.
On Nov 30, 2012, at 10:30 AM, Helena Mitasova wrote: On Nov 30, 2012, at 10:08 AM, William Kyngesburye wrote: This could happen if you configured for wxPython 2.9 64bit, but didn't bundle it so it finds the old 32bit wxPython 2.8 in the system at runtime. If you configure for wxPython 2.8 you should not get arch errors, at least if you make sure to configure 32+64bit. I am pretty sure this is my case - can you please look at my configure and if possible give my some hints on what should I do differently? Thank you, Helena Well, you're configuring OK - 32+64bit, system wxpython 2.8 (32bit). Though the system wxpython is technically within the minimum version, it's a bit old, but it shouldn't have an affect on the architectures. The enable-64bit option is meaningless on OS X, the archs option handles all we need for 64bit. I do recall issues with the debug flag (not sure if it was GRASS or something else). Try removing -g from CFLAGS, or change it to -Os. One way to check if it configured correctly for wxpython archs is to look at platform.make, MACOSX_ARCHS_WXPYTHON. There should be only i386 there. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
On Nov 12, 2012, at 10:57 AM, Michael Barton wrote: From what I can tell... Volumes work on 10.6 when compiled on 10.6 Volumes do not work on any system when compiled on 10.8 Volumes compiled on 10.6 do not work on 10.8 (I think, but this needs a little more testing) From my testing: compiled on/for 10.7 and Python 2.7, run on 10.7: crash compiled on/for 10.7 and Python 2.7, run on 10.8 (essentially same as 10.7 for runtime compatibility): crash compiled on 10.6 for 10.6 and Python 2.6, run on 10.6: OK compiled on 10.6 for 10.6 and Python 2.6, run on 10.7+: crash all using Wxpython 2.8. Note that wx 2.8 is _probably_ not compatible with OS X 10.7+ because of Carbon issues. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
Well, on the Mac, it comes with the Python Apple provides, but as Glynn says it is not a part of the standard Python package. It looks like it's been included since Python 2.5 on OS X. On Oct 23, 2012, at 12:23 PM, Michael Barton wrote: So now I'm confused. Does it come with the Python that comes with Macs and can be installed (normal install) on Windows? Or is it something that needs to be installed separately? Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Oct 23, 2012, at 8:46 AM, Glynn Clements gl...@gclements.plus.com wrote: Michael Barton wrote: I want to retract my concern over dateutil. Both William and Helena have shown that it IS available in the default Python distribution. It isn't, however, part of the Python standard library, so it needs to be explicitly listed as a dependency, distinct from Python. I have no particular opinion as to whether or not dateutil should be used, but it should not be an optional dependency. I.e. either require it or don't use it, but don't offer two subtly-different APIs. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH not defined during compilation in rel6.4
On Oct 22, 2012, at 9:35 AM, Glynn Clements wrote: William Kyngesburye wrote: Trying to compile release 6.4 branch today, and it fails creating menudata.py menustrings.py, right? right. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
Yes, it is in the system python lib folder on all the Macs I checked. /System/Library/Frameworks/Python.framework/Versions/2.x/Extras/lib/python/dateutil If compilation of matplotlib found it is missing, it would put it in the user site-packages folder (it does so for pytz and mpl_toolkits). On Oct 20, 2012, at 11:35 PM, Michael Barton wrote: Are you sure it is there originally? Or is it present because you have installed other python apps like MatPlotLib? Thinking about this, it is really odd that it would somehow stop the GUI from loading at startup. Is there some kind of test for dateutil that happens at startup? Even if dateutil is missing, there should not be a crash or error until one of the modules that needs it is run and 'import datetuil' generates an error. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Oct 18, 2012, at 6:43 AM, William Kyngesburye wokl...@kyngchaos.com wrote: I just got some time to briefly look at this - dateutil IS in OS X Python, 2.6 and 2.7. (checked OS X Lion and Snow Leopard) So if Mac users are having problems with a missing dateutil, then maybe they have another Python installed, like from python.org or MacPorts or Homebrew. Then it's really a problem of installing dateutil in that other distribution. On Oct 17, 2012, at 2:09 PM, Michael Barton wrote: This seems like a good idea. Gives us time to think about the value and costs of using and bundling dateutil. Michael Barton School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University ...Sent from my iPad On Oct 17, 2012, at 11:34 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 17/10/12 13:21, Sören Gebbert wrote: Hi Michael, sorry to introduce something painful as a python-dateutil dependency. My fault. I should have discussed this on the list indeed. I have completely removed the dateutil dependency from the temporal GIS in r53435. For now only two types of calendar time stings are supported for parsing. Do you really have to remove it completely ? Can't you check for its presence and if not present fall back on the basic date version ? And put a hint in the manuals about its installation being strongly recommended ? Moritz - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Time is an illusion - lunchtime doubly so. - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] PYTHONPATH not defined during compilation in rel6.4
Trying to compile release 6.4 branch today, and it fails creating menudata.py because the PYTHONPATH is not defined to find grass.script. I see a r49620 from a while back that fixes this (dev6 branch compiles without this error) - maybe this should be backported to release 6.4? http://trac.osgeo.org/grass/changeset/49620 - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] dateutil dependency killing GRASS 7
I just got some time to briefly look at this - dateutil IS in OS X Python, 2.6 and 2.7. (checked OS X Lion and Snow Leopard) So if Mac users are having problems with a missing dateutil, then maybe they have another Python installed, like from python.org or MacPorts or Homebrew. Then it's really a problem of installing dateutil in that other distribution. On Oct 17, 2012, at 2:09 PM, Michael Barton wrote: This seems like a good idea. Gives us time to think about the value and costs of using and bundling dateutil. Michael Barton School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University ...Sent from my iPad On Oct 17, 2012, at 11:34 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 17/10/12 13:21, Sören Gebbert wrote: Hi Michael, sorry to introduce something painful as a python-dateutil dependency. My fault. I should have discussed this on the list indeed. I have completely removed the dateutil dependency from the temporal GIS in r53435. For now only two types of calendar time stings are supported for parsing. Do you really have to remove it completely ? Can't you check for its presence and if not present fall back on the basic date version ? And put a hint in the manuals about its installation being strongly recommended ? Moritz - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.viewshed does not compile in GRASS 7 either
Just tried something - it's definitely a clang problem. Probably more strict,
as I thought, about some C++ stuff by default.
It was working for me because of how Apple has the dev tools set up and how
GRASS configure detects cc/c++. For me, on Lion/Xcode 4.3, I have a bunch of
symlinks:
/usr/bin/cc - /usr/bin/clang
/usr/bin/c++ - /usr/bin/clang
/usr/bin/gcc - /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
/usr/bin/g++ - /usr/llvm-gcc-4.2/bin/llvm-g++-4.2
And it appears that GRASS is preferring gcc/g++ in configuration. llvm, as I
understand, is more of an intermediate compiler made to closely emulate gcc
behavior.
Maybe on Mt Lion, those symlinks are different so that GRASS uses clang instead
of llvm. It's possible I have leftovers from a previous Xcode.
What did GRASS find for CC and CXX? (see include/make/platform.make)
What do you have for the /usr/bin compilers?
On Sep 3, 2012, at 4:15 PM, Michael Barton wrote:
r.viewshed and r.terraflow problems in compiling seem to have the same cause
Michael
Begin forwarded message:
From: William Kyngesburye kyngch...@kyngchaos.com
Subject: Re: r.viewshed does not compile in GRASS 7 either
Date: September 3, 2012 2:10:02 PM MST
To: Michael Barton michael.bar...@asu.edu
same error as the r.terraflow error you found a few days ago ;)
On Sep 3, 2012, at 4:02 PM, Michael Barton wrote:
So r.viewshed doesn't compile either now (probably didn't a few days ago,
but I didn't see it because of all the temporal module errors. I just did a
ticket.
Michael
Here is the error:
Last login: Mon Sep 3 13:55:06 on ttys000
Michaels-MacBook-Air:~ cmbarton$ cd
/Users/Shared/grass_dev/grass70_dev/raster/r.viewshed
Michaels-MacBook-Air:r.viewshed cmbarton$ make
c++ -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk
-I/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include
-I/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include
-D_FILE_OFFSET_BITS=64 -DUSER=\cmbarton\ -Wno-sign-compare
-DPACKAGE=\grassmods\
-I/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include
-I/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include
-o OBJ.x86_64-apple-darwin12.1.0/distribute.o -c distribute.cpp
In file included from distribute.cpp:52:
In file included from
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include/grass/iostream/ami.h:56:
In file included from
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include/grass/iostream/empq_impl.h:43:
In file included from
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include/grass/iostream/empq.h:51:
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include/grass/iostream/embuffer.h:1140:56:
error:
default arguments cannot be added to an out-of-line definition of a
member
of a class template
long em_bufferT,Key::insert(AMI_STREAMT* str, long bos=0) {
^ ~
In file included from distribute.cpp:52:
In file included from
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include/grass/iostream/ami.h:56:
In file included from
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include/grass/iostream/empq_impl.h:43:
In file included from
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include/grass/iostream/empq.h:53:
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.1.0/include/grass/iostream/minmaxheap.h:512:7:
error:
reference to non-static member function must be called; did you mean to
call it with no arguments?
if (size) {
^~~~
()
-
William Kyngesburye kyngchaos*at*kyngchaos*dot*com
http://www.kyngchaos.com/
I ache, therefore I am. Or in my case - I am, therefore I ache.
- Marvin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.viewshed does not compile in GRASS 7 either
On Sep 3, 2012, at 4:53 PM, Michael Barton wrote: On Sep 3, 2012, at 2:42 PM, William Kyngesburye wokl...@kyngchaos.com wrote: Just tried something - it's definitely a clang problem. Probably more strict, as I thought, about some C++ stuff by default. It was working for me because of how Apple has the dev tools set up and how GRASS configure detects cc/c++. For me, on Lion/Xcode 4.3, I have a bunch of symlinks: /usr/bin/cc - /usr/bin/clang /usr/bin/c++ - /usr/bin/clang /usr/bin/gcc - /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 /usr/bin/g++ - /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 And it appears that GRASS is preferring gcc/g++ in configuration. llvm, as I understand, is more of an intermediate compiler made to closely emulate gcc behavior. Maybe on Mt Lion, those symlinks are different so that GRASS uses clang instead of llvm. It's possible I have leftovers from a previous Xcode. What did GRASS find for CC and CXX? (see include/make/platform.make) CC = gcc [could this be a problem???] CXX = c++ no, CXX is the problem (r.terraform and r.viewshed are C++). It should be g++ so it's using llvm. If GRASS is finding c++ by default, force it to what you want - add to your configure: CXX=g++ - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Time is an illusion - lunchtime doubly so. - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] possible problem with r.terraflow
: warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat] G_message( \t\t FILL: %s [%d elements, %dB each], ~^ %ld main.cc:437:45: warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat] G_message( \t\t FLOW: %s [%ld elements, %dB each], ~^ %ld 8 warnings and 2 errors generated. make: *** [OBJ.x86_64-apple-darwin12.1.0/FLOAT/main.o] Error 1 C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Time is an illusion - lunchtime doubly so. - Ford Prefect - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] liblas compiling?
Looks like you didn'y compile liblas for multi-arch, just the default 64bit.
You need to add an option to liblas cmake config:
-D CMAKE_OSX_ARCHITECTURES=i386;x86_64
On Aug 8, 2012, at 10:49 AM, Michael Barton wrote:
Here is what config.log says:
configure:6325: checking whether to use libLAS
configure:6342: checking for liblas-config
configure:6397: gcc -o conftest -g -O2 -arch i386 -arch x86_64 -arch
i386 -arch x86_64 conftest.c -L/usr/local/lib -llas -llas_c
-L/usr/local/lib /usr/local/lib/libboost_program_options.dylib
/usr/local/lib/libboost_thread.dylib 15
ld: warning: in /usr/local/lib/liblas.dylib, file was built for unsupported
file format which is not the architecture being linked (i386)
ld: warning: in /usr/local/lib/liblas_c.dylib, file was built for unsupported
file format which is not the architecture being linked (i386)
ld: warning: in /usr/local/lib/libboost_program_options.dylib, file was built
for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /usr/local/lib/libboost_thread.dylib, file was built for
unsupported file format which is not the architecture being linked (i386)
Undefined symbols for architecture i386:
_LASReader_Create, referenced from:
_main in ccyGPRwA.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
lipo: can't open input file:
/var/folders/AK/AKpYwDw1EoWI+fFF02nvRk+++TI/-Tmp-//ccTBIoSr.out (No such file
or directory)
configure: failed program was:
#line 6390 configure
#include confdefs.h
#include liblas/capi/liblas.h
int main() {
LASReader_Create(foo);
; return 0; }
configure:6412: gcc -o conftest -g -O2 -arch i386 -arch x86_64 -arch
i386 -arch x86_64 conftest.c -L/usr/local/lib -llas -llas_c
-L/usr/local/lib /usr/local/lib/libboost_program_options.dylib
/usr/local/lib/libboost_thread.dylib 15
ld: warning: in /usr/local/lib/liblas.dylib, file was built for unsupported
file format which is not the architecture being linked (i386)
ld: warning: in /usr/local/lib/liblas_c.dylib, file was built for unsupported
file format which is not the architecture being linked (i386)
ld: warning: in /usr/local/lib/libboost_program_options.dylib, file was built
for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /usr/local/lib/libboost_thread.dylib, file was built for
unsupported file format which is not the architecture being linked (i386)
Undefined symbols for architecture i386:
_LASReader_Create, referenced from:
_main in ccyd6eSx.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
lipo: can't open input file:
/var/folders/AK/AKpYwDw1EoWI+fFF02nvRk+++TI/-Tmp-//cc1EN6Pu.out (No such file
or directory)
configure: failed program was:
#line 6405 configure
#include confdefs.h
#include liblas/capi/liblas.h
int main() {
LASReader_Create(foo);
; return 0; }
I tried adding an explicit --with-liblas-includes= statement, but it still
bombs.
Michael
On Aug 7, 2012, at 4:36 PM, William Kyngesburye wrote:
check config.log, this should tell you why.
On Aug 7, 2012, at 4:23 PM, Michael Barton wrote:
I'm trying to compile GRASS 7 with LAS support.
I've compiled liblas and it is in usr/local/lib, with utility programs and
config in /usr/local/bin
I added --with-liblas=/usr/local/bin/liblas-config to my configure script,
since this is where liblas-config is located. Moreover, it seems to work
OK.
running liblas-config produces the following output, which seems fine
AFAICT
cmb-macbookpro:~ cmbarton$ /usr/local/bin/liblas-config --libs
-L/usr/local/lib -llas -llas_c -L/usr/local/lib
/usr/local/lib/libboost_program_options.dylib
/usr/local/lib/libboost_thread.dylib
Yet configure produces an error that it cannot find the liblas libraries.
Any suggestions?
Michael
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice:
480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www:
http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
-
William Kyngesburye kyngchaos*at*kyngchaos*dot*com
http://www.kyngchaos.com/
Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting,
and all for things that the beasts of the jungle would not deign to possess
- money to purchase the effeminate pleasures of weaklings. And yet withal
bound down by silly customs that make them slaves to their unhappy lot while
firm in the belief that they be the lords of creation
Re: [GRASS-dev] liblas compiling?
check config.log, this should tell you why. On Aug 7, 2012, at 4:23 PM, Michael Barton wrote: I'm trying to compile GRASS 7 with LAS support. I've compiled liblas and it is in usr/local/lib, with utility programs and config in /usr/local/bin I added --with-liblas=/usr/local/bin/liblas-config to my configure script, since this is where liblas-config is located. Moreover, it seems to work OK. running liblas-config produces the following output, which seems fine AFAICT cmb-macbookpro:~ cmbarton$ /usr/local/bin/liblas-config --libs -L/usr/local/lib -llas -llas_c -L/usr/local/lib /usr/local/lib/libboost_program_options.dylib /usr/local/lib/libboost_thread.dylib Yet configure produces an error that it cannot find the liblas libraries. Any suggestions? Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] locale problem - configuration fails with nls
It's in the libintl library, not Python gettext. Another dependency to worry about on OS X. I'll dig up my notes later this evening for you. On Aug 1, 2012, at 12:15 PM, Michael Barton wrote: I've never compiled --with-nls prior to this. However, at least a few years back, GRASS that I compiled came up in Spanish on my colleague's machines--either because the with-nls flag dates to a few years back or because it worked in spite of not compiling with-nls. No one told me when this stopped working and my builds were only in English, so I'm in the dark on that. I just tried to compile with-nls, but got this config error checking whether to use NLS... yes checking for gettext... no checking for gettext in -lintl... no configure: error: *** Unable to locate gettext() function. I KNOW that I have python gettext. So how do I specify it? Or is this a non-Python gettext that I must install separately? Michael On Aug 1, 2012, at 8:44 AM, Glynn Clements wrote: Michael Barton wrote: I have not explicitly built with --with-nls. Is this required for GRASS to use different language settings (i.e., po.* files)? For C modules and libraries, yes. Python code will probably ignore the --with-nls setting. -- Glynn Clements gl...@gclements.plus.com _ C. Michael Barton Visiting Scientist, Integrated Science Program National Center for Atmospheric Research University Corporation for Atmospheric Research 303-497-2889 (voice) Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] more on locale problem - workaround success!
On Jul 28, 2012, at 11:56 AM, Michael Barton wrote: So by default, my LANG is set but none of the other locale variables are set. For Carlos, LC_CTYPE is set (incorrectly??) and nothing else (including LANG) is set. Neither one of us have explicitly set any of these locale variables prior to hitting this issue. Since another Spanish colleague (Agustin) also reported problems, I wonder if this is something that is normal for Spanish-enabled Macs. Note that LANG is set automatically by Terminal.app if the Advanced preference Set locale environment variables on startup is checked. But, of course, this is useless if the system sets LC_CTYPE somewhere. I have doubts that it is something specific to Spanish or other non-English systems. Others that have reported this in the past have had problems on English systems and some non-English system users have not had the problem. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] one locale problem red herring
GRASS should not be automatically adding the desktop (ie ~/Desktop) to GRASS_ADDON_PATH. In the Mac startup, it should only be ~/Library/GRASS/6.4/Modules/bin /Library/GRASS/6.4/Modules/bin (substitute GRASS version), plus anything the user set for GRASS_ADDON_PATH in .bash_profile or other shell init. On Jul 28, 2012, at 2:52 PM, Michael Barton wrote: So I am digging into why GRASS GUI is crashing on start up. A couple days ago, I found that adding the LANG: ... line to .grassrc6 prevented this. In continuing to dig into this today, I think that fix was a red herring. That is not why it is crashing. The reason it is crashing is because the Mac desktop is by default added to GRASS_ADDON_PATH and globalvar.py is grabbing some hidden, non-parsable file names when it scans the desktop for GRASS commands. I don't understand why it is getting these hidden files from the desktop and not getting the same junk when it scans other folders, but the most limited fix for this is adding... if fname[0:2] not in ['d.','g.','r.','v.','i.','m.','p.','r3','db']: continue after line 153 in globalvar.py To make sure that globalvar.py only picks up legitimate commands, however, it would probably be good to add something like this to all folder scans or maybe to filter the resulting command list before it is returned. Before doing either of those, I want to make sure that I have not missed any GRASS command prefixes. Does this list look comprehensive? ['d.','g.','r.','v.','i.','m.','p.','r3','db'] After this issue is solved, I can look again at the locale issue. It *looks* like it should be doing the right thing (the change set I quoted yesterday was out of date), but something is not quite working somewhere. Michael _ C. Michael Barton Visiting Scientist, Integrated Science Program National Center for Atmospheric Research University Consortium for Atmospheric Research 303-497-2889 (voice) Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - 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-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] more on locale problem
Set it in ~/.bash_profile, I don't think Terminal on OS X reads ~/.bashrc. On Jul 27, 2012, at 10:45 PM, Michael Barton wrote: Tried it. Didn't work. Any other ideas? I'm completely out of thoughts on this beyond roll back to before the change. Michael On Jul 27, 2012, at 7:02 PM, Hamish wrote: Michael: Unfortunately, putting this into .grass.bashrc doesn't work, nor does putting this into .profile nor .grassrc6 (a long shot). how about exporting it in ~/.bashrc? If put in .grass.bashrc it might only be found if you start the gui from the GRASS terminal prompt with g.gui, since it gets sourced late in the game. Hamish _ C. Michael Barton Visiting Scientist, Integrated Science Program National Center for Atmospheric Research University Consortium for Atmospheric Research 303-497-2889 (voice) Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] more on locale problem
As you mentioned Michael, there was discussion of this problem a few times in the past. The problem setting is not LANG, though, it's LC_CTYPE. The system is somehow setting that to UTF-8, and Python checks LC_CTYPE (and LC_ALL next) before it checks LANG, so setting LANG in GRASS won't help, as Agustin found. On Jul 26, 2012, at 5:03 AM, Agustin Angel Diez Castillo wrote: Michael and others, Michael's 6.4.3 menus aren't working here, I did try adding en_US.UTF-8 to .grassrc6 but the complaints are the same ERROR: unknown locale: UTF-8 ERROR: unknown locale: UTF-8 ERROR: unknown locale: UTF-8 ERROR: unknown locale: UTF-8 ERROR: unknown locale: UTF-8 ERROR: unknown locale: UTF-8 2012-07-26 11:56:43.011 Python[1916:e0f] CFURLCreateWithString was passed this invalid URL string: '/System/Library/CoreServices/CommonCocoaPanels.bundle' (a file system path instead of an URL string). The URL created will not work with most file URL functions. CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemPathRelativeToBase should be used instead. by the way my system preferences are set to english but the region is set to Spain. cli is working As you know in R the language is forced with defaults write org.R-project.R force.LANG en_US.UTF-8 Is there something similar in GRASS? A On Thursday, July 26, 2012 08:16 CEST, Michael Barton michael.bar...@asu.edu wrote: So I am now completely baffled as to why GRASS is not working on my colleague's computer. it is a pretty new MacBook (last 6 months) and he has not installed much on it--Office, Mendeley. It is running the most current version of Lion (10.7.4). There are repeated problems with locale on it. Here is an example that works fine on my computer also running Lion. import locale locale.getdefaultlocale() Traceback (most recent call last): File stdin, line 1, in module File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 496, in getdefaultlocale File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 428, in _parse_localename ValueError: unknown locale: UTF-8 I don't know where it is getting UTF-8. The GUI code in GRASS calls the language en_ES.UTF-8, but this is running Python outside of GRASS. I've tried setting locale to es_EN, and to C. But we still get this error when locale.getdefaultlocale() is run in wx GUI. Any ideas? Michael - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] GRASS, ArcGIS, and Python incompatibilties
I guess technically it could use the system wxpython. But I can think of a few reasons to still bundle wxpython: - bug fixes in later versions than the system version that greatly affect use in GRASS (I don't remember, but I think there were some?) - consistency of behavior across system versions from having the same wxpython - 64bit support in wxpython 2.9 when GRASS is happy with 2.9 (or whatever the release version is, 2.10?) - simply that wxpython is not included in the system starting with OS X 10.7 On Jun 30, 2012, at 10:28 PM, Michael Barton wrote: Does this mean that we no longer *have* to bundle wxPython with the Mac binaries? That they will work with whatever wxPython is installed (assuming it is within the range of supported versions, of course) regardless of what it was compiled with? Michael On Jun 30, 2012, at 4:32 PM, Glynn Clements wrote: Michael Barton wrote: Don't you need to have the wxPython that GRASS was compiled with? And doesn't this wxPython have to match the Python version? GRASS isn't compiled with any version of Python, i.e. it doesn't have any binaries which link against the Python DLL/DSO. At one time there were binary modules for the wx GUI's nviz and vdigit components, and the SWIG wrappers, but those have all since been eliminated. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Indented comments in Makefile not compatible with make-3.82
When I created the modbuild thing way back when, that multiline sed replacement did not work (It does work directly in the Terminal). I *think* it ended up as run together on one line. Maybe there was a problem with the OS X make at the time. I haven't looked at it since. On Jun 1, 2012, at 2:28 AM, Glynn Clements wrote: Daniel Macks wrote: The problem appears to be just after the above sed command, where macosx/modbuild/Makefile has: @# until I figure out how to get sed to replace with multiple lines in a @# makefile, GRASS_APP required for modbuild, ie no default to /Applications @#-e 's#^GISBASE.*#ifdef GRASS_APP\ @#GISBASE = $$(GRASS_APP)/Contents/MacOS\ @#else\ @#GISBASE = $(INST_DIR_MACOSX)\ @#endif#g' @# html.make needs a little change Why is it even looking at the syntax of a comment? The commented-out section is confusing because it's a hybrid of makefile-recipe quiet tags (@), makefile commenting (#), and makefile and shell line-continuations (). The new make is known to be stricter about several types of makefile syntax, so maybe you've triggered one of those? The use of the apparently non-standard @# in general does not seem to be the problem, or else the modbuild recipe would have crashed even earlier, so it must be related to the multilining in them. Changing the commented-out sed chunk to use standard commenting (non-indented leading #) works for me: Make parses the above as four shell commands: # until I figure out how to get sed to replace with multiple lines in a # makefile, GRASS_APP required for modbuild, ie no default to /Applications #-e 's#^GISBASE.*#ifdef GRASS_APP\ @#GISBASE = $$(GRASS_APP)/Contents/MacOS\ @#else\ @#GISBASE = $(INST_DIR_MACOSX)\ @#endif#g' @# html.make needs a little change For the third one (which is causing the problem), the entire block is executed as a single command, including the backslash-newline pairs and the @ at the start of each line other than the first. It's the leading @ which causes the problem; a # only begins a comment when it appears at the beginning of a word: $ pwd #asdfasdf /home/glynn $ pwd#asdfasdf bash: pwd#asdfasdf: command not found Also, backslash-newline elimination isn't performed within comments. Consequently, the shell parses the string as two commands: #-e 's#^GISBASE.*#ifdef GRASS_APP\ @#GISBASE = $$(GRASS_APP)/Contents/MacOS @#else @#GISBASE = $(INST_DIR_MACOSX) @#endif#g' The first is a comment, the second isn't. The comment swallows the opening single quote, so what should be the closing quote is actually the opening quote. The fact that the actual command is gibberish doesn't matter, because the shell never gets beyond the first phases of parsing, due to the mismatched quote. Removing the leading '@' from each continuation line should suffice, i.e.: @# until I figure out how to get sed to replace with multiple lines in a @# makefile, GRASS_APP required for modbuild, ie no default to /Applications @#-e 's#^GISBASE.*#ifdef GRASS_APP\ #GISBASE = $$(GRASS_APP)/Contents/MacOS\ #else\ #GISBASE = $(INST_DIR_MACOSX)\ #endif#g' # html.make needs a little change BTW, I'm not sure why this is commented out; the sed expression should actually work as-is, i.e.: -e 's#^GISBASE.*#ifdef GRASS_APP\ GISBASE = $$(GRASS_APP)/Contents/MacOS\ else\ GISBASE = $(INST_DIR_MACOSX)\ endif#g' Make should pass backslash-newline through to the shell, the shell should pass it through to sed (being in a single-quoted string), and sed recognises backslash-newline as a literal newline in the replacement of an 's' command. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] missing GetToolEnabled for digitizer in GRASS 6.4.2
Hey, I can stop digitizing now! Thanks. I'll package updated OS X GRASS as soon as I can. On Mar 9, 2012, at 7:03 AM, Martin Landa wrote: Hi, 2012/2/27 Michael Barton michael.bar...@asu.edu: I think I've found the reason that you cannot stop digitizing with a right click in GRASS 6.4.2. A right click ultimately makes a call to GetToolEnabled. Either this method was never backported to 6.4.2 or the module that contains it is not imported. Because of the reorganized structure in 6.4.3, I can't tell where this is supposed to be in 6.4.2. Hopefully one of you recognize it and can find it. ops, this bug has been introduced by me [1] (2012/01/19, so one month before 6.4.2 release). The undo didn't work perfectly in GRASS 6, so I decided to remove this tool from the toolbar, unfortunately there is the side-effect you noted. I did some tests on GNU/Linux where everything works (wxWidgest is not so strict when using GTK). Anyway I can reproduce this bug on Windows. The patch suggested by Anna is OK, the problem is that we can hardly apply it in `relbr64` for 6.4.2 (code base changed a lot since 6.4.2 has been released). So at this point we would need to force packagers to apply the patch locally. Happily it's related only to Windows (I will do the job) and Mac OS X (William?). Unfortunately I don't know about better solution. WinGRASS: fixed version uploaded to grass.osgeo.org [2] and OSGeo4W (`grass-6.4.2-3`). Linux version should be unaffected. Mac OS X package needs to be updated (see patch at [3]). Testing highly welcomed (open vector digitizer, digitize new feature). Martin [1] http://trac.osgeo.org/grass/changeset/50301/grass/branches/releasebranch_6_4/gui/wxpython/gui_modules/toolbars.py [2] http://grass.osgeo.org/grass64/binary/mswindows/native/ [3] http://josef.fsv.cvut.cz/~landa/wingrass/wingrass-642.diff -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PIL needs to be a GRASS dependency
On Nov 23, 2011, at 12:03 AM, Michael Barton wrote: Thanks William. Your package makes this work OK. I had only been able to install PIL for Python 2.7, but had compiled GRASS 7 with Python 2.6. This left the cartographic composer only partly workable. This could be a problem for others. Actually, this is am oversight by me. While I install for python 2.6 AND 2.7 on Lion with my frameworks (osgeo.gdal, pysqlite), I forgot to do the same for non-framework python modules. Easily fixed. These extra python packages not only need to be installed, but need to be installed for whatever version of Python that GRASS is compiled with. This is a similar issue to what we ran into with wxPython. I don't know how this is handled in Windows, but could potentially be a problem there too. I'm not sure how to best handle this. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Nov 22, 2011, at 9:05 PM, William Kyngesburye wrote: Well, I have Mac PIL and Numpy packages. I don't think Python modules are something you should be bundling in GRASS binaries, since users may already have them installed. If the GRASS installer (at least on OS X) could check for dependencies it wouldn't such a problem, since GRASS would simply not install and tell you what is missing. That's been a low priority on my list to do for a while - add some mechanism for extending the installer creation in the bindist target, to allow packagers to specify dependency checks (it's not something that's easy or practical to do automatically based on configured dependencies). On Nov 22, 2011, at 9:16 PM, Michael Barton wrote: Since the Python Imaging Library (PIL) is needed to fully use the cartographic composer, this needs to be a dependency of GRASS, just like numpy. Since both of these packages do not come with the standard Python distribution, it would be good if we could package/bundle them in binary distributions. Otherwise, stuff will not work. This is needed for GRASS 6.4 as well as GRASS 7. I'm not sure what is needed for this to happen, but it will be helpful to users (and very frustrating to them if not there). Michael - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PIL needs to be a GRASS dependency
Well, I have Mac PIL and Numpy packages. I don't think Python modules are something you should be bundling in GRASS binaries, since users may already have them installed. If the GRASS installer (at least on OS X) could check for dependencies it wouldn't such a problem, since GRASS would simply not install and tell you what is missing. That's been a low priority on my list to do for a while - add some mechanism for extending the installer creation in the bindist target, to allow packagers to specify dependency checks (it's not something that's easy or practical to do automatically based on configured dependencies). On Nov 22, 2011, at 9:16 PM, Michael Barton wrote: Since the Python Imaging Library (PIL) is needed to fully use the cartographic composer, this needs to be a dependency of GRASS, just like numpy. Since both of these packages do not come with the standard Python distribution, it would be good if we could package/bundle them in binary distributions. Otherwise, stuff will not work. This is needed for GRASS 6.4 as well as GRASS 7. I'm not sure what is needed for this to happen, but it will be helpful to users (and very frustrating to them if not there). Michael - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r48782 - grass/branches/releasebranch_6_4/macosx/app
Gr, I read init.sh wrong. On Oct 13, 2011, at 9:16 AM, Martin Landa wrote: 2011/10/13 svn_gr...@osgeo.org: Author: kyngchaos Date: 2011-10-13 06:50:40 -0700 (Thu, 13 Oct 2011) New Revision: 48782 Modified: grass/branches/releasebranch_6_4/macosx/app/grass.sh.in Log: modules folder is a prefix now AFAIK it's true only for G7. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Those people who most want to rule people are, ipso-facto, those least suited to do it. - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r48782 - grass/branches/releasebranch_6_4/macosx/app
I wonder if the Grass 7 prefix definition should be backported, since 6.x has g.extension as well. On Oct 13, 2011, at 10:00 AM, William Kyngesburye wrote: Gr, I read init.sh wrong. On Oct 13, 2011, at 9:16 AM, Martin Landa wrote: 2011/10/13 svn_gr...@osgeo.org: Author: kyngchaos Date: 2011-10-13 06:50:40 -0700 (Thu, 13 Oct 2011) New Revision: 48782 Modified: grass/branches/releasebranch_6_4/macosx/app/grass.sh.in Log: modules folder is a prefix now AFAIK it's true only for G7. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Those people who most want to rule people are, ipso-facto, those least suited to do it. - A rule of the universe, from the HitchHiker's Guide to the Galaxy - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [Qgis-user] Status of the qgis-grass plugin, esp. on Windows
Don't forget OS X - the grass plugin is currently broken for OS X as a result of a fix for Windows: http://hub.qgis.org/issues/3999 On Sep 9, 2011, at 2:35 PM, Paolo Cavallini wrote: Hi all. As qgis-grass-windows user know, we had a couple of nasty bugs [0],[1] preventing a proper use of GRASS within QGIS on Windows. One of the bugs seemed fixed upstream, but we still missed an osgeo4w package for it. We (Faunalia) do not use Windows, but we do a lot of courses, and many users have Windows machines, so we had the choice of either removing GRASS from our courses or get our hands dirty and debug GRASS and its QGIS plugin on Win. Of course we did the latter. We believe now everything should be solved, so all well. However, we would like to point out that: - a grass-dev package, built overnight, is missing from osgeo4w; we think this is quite bad, as testing on win lags very much behind in this way; of course grass-only users can install the standalone, but we think a complete environment is better; IOHO this should not be hard to set up, so we encourage GRASS maintainers to do so (AFAIK Martin Landa is working on this); of course we're ready to help if necessary - the qgis-grass plugin is receiving very little, if any, care; I think we (Faunalia) did most of the work on it in the last few years; we're happy to do it, but we miss the resource to do it on a regular basis (e.g. there is a number of bugs to be fixed). Are we the only users, or there are more around? If so, please stand up and help us, either patching the code or providing some resources, or even better becoming the maintainer of the plugin, otherwise we're afraid the maintenance will become more and more difficult. All the best. [Giuseppe | Giovanni | Paolo] @ Faunalia -- Paolo Cavallini - Faunalia www.faunalia.eu See details at: www.faunalia.eu/pc [0] http://trac.osgeo.org/grass/ticket/1158 [1] http://hub.qgis.org/issues/3646 ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxGUI on mac
From my tests, the problem is not 64bit wxpython, it's wxpython 2.9 Cocoa. The GUI crashes on startup for both 64bit and 32bit modes. The 2.9 Cocoa build is an absolute must for Lion because (as I understand it) all the last deprecated Carbon APIs have been removed. wxpython 2.8 (Carbon) built for the python 2.6 on Snow *seems* to work on Lion, though there may be some hidden Carbon dependencies that won't cause trouble until they're used. And for some it crashes when quitting the GUI. On Aug 31, 2011, at 3:35 PM, Massimo Di Stefano wrote: Hi All, I'm on lion too, but before lion my problem with wx and snow leopard was that i'm using python 64 bit (and wx is not ready yet) The last time i tried to update my wx to 2.9.x to be able to have all running as 64bit i had lot of problems so i switched to the old tcltk gui for a stable usage. i'll provide as soon as possible all the issue i'm having running wxpython (using python.org) in 64 bit mode on both snow leopard and lion. --Massimo. . Il giorno 31/ago/2011, alle ore 22.01, Helena Mitasova ha scritto: More serious issue with Mac is getting GRASS with wxGUI running on Lion, I just got first student with new Mac running Lion and she is using MSWindows on Mac to run GRASS. If anybody has any advice on running GRASS on Lion please let me know, Helena - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] OS X Lion: wxpython 2.9
0x0001006e2e0a PyEval_EvalFrameEx + 14008 44 org.python.python 0x0001006e5cd8 PyEval_EvalCodeEx + 1996 45 org.python.python 0x000100683abf 0x10065b000 + 166591 46 org.python.python 0x000100662d32 PyObject_Call + 97 47 org.python.python 0x0001006716e9 0x10065b000 + 91881 48 org.python.python 0x000100662d32 PyObject_Call + 97 49 org.python.python 0x0001006ad484 0x10065b000 + 337028 50 org.python.python 0x0001006a7b7a 0x10065b000 + 314234 51 org.python.python 0x000100662d32 PyObject_Call + 97 52 org.python.python 0x0001006e2f63 PyEval_EvalFrameEx + 14353 53 org.python.python 0x0001006e5cd8 PyEval_EvalCodeEx + 1996 54 org.python.python 0x000100683abf 0x10065b000 + 166591 55 org.python.python 0x000100662d32 PyObject_Call + 97 56 org.python.python 0x0001006716e9 0x10065b000 + 91881 57 org.python.python 0x000100662d32 PyObject_Call + 97 58 org.python.python 0x0001006dec40 PyEval_CallObjectWithKeywords + 180 59 _core_.so 0x000100e78ebe wxPyApp::_BootstrapApp() + 766 60 _core_.so 0x000100eb8a1b _wrap_PyApp__BootstrapApp + 75 61 org.python.python 0x0001006e35d8 PyEval_EvalFrameEx + 16006 62 org.python.python 0x0001006e5cd8 PyEval_EvalCodeEx + 1996 63 org.python.python 0x0001006e5e6c 0x10065b000 + 568940 64 org.python.python 0x0001006e2e0a PyEval_EvalFrameEx + 14008 65 org.python.python 0x0001006e5cd8 PyEval_EvalCodeEx + 1996 66 org.python.python 0x000100683abf 0x10065b000 + 166591 67 org.python.python 0x000100662d32 PyObject_Call + 97 68 org.python.python 0x0001006716e9 0x10065b000 + 91881 69 org.python.python 0x000100662d32 PyObject_Call + 97 70 org.python.python 0x0001006e2f63 PyEval_EvalFrameEx + 14353 71 org.python.python 0x0001006e5cd8 PyEval_EvalCodeEx + 1996 72 org.python.python 0x000100683abf 0x10065b000 + 166591 73 org.python.python 0x000100662d32 PyObject_Call + 97 74 org.python.python 0x0001006716e9 0x10065b000 + 91881 75 org.python.python 0x000100662d32 PyObject_Call + 97 76 org.python.python 0x0001006ad484 0x10065b000 + 337028 77 org.python.python 0x0001006a7b7a 0x10065b000 + 314234 78 org.python.python 0x000100662d32 PyObject_Call + 97 79 org.python.python 0x0001006e2f63 PyEval_EvalFrameEx + 14353 80 org.python.python 0x0001006e5cd8 PyEval_EvalCodeEx + 1996 81 org.python.python 0x0001006e5e6c 0x10065b000 + 568940 82 org.python.python 0x0001006e2e0a PyEval_EvalFrameEx + 14008 83 org.python.python 0x0001006e5cd8 PyEval_EvalCodeEx + 1996 84 org.python.python 0x0001006e5d4d PyEval_EvalCode + 54 85 org.python.python 0x0001006fd08f 0x10065b000 + 663695 86 org.python.python 0x0001006fd14f PyRun_FileExFlags + 157 87 org.python.python 0x0001006fe2a2 PyRun_SimpleFileExFlags + 392 88 org.python.python 0x00010070e2af Py_Main + 2715 89 org.python.python 0x000100653e88 0x100653000 + 3720 On Aug 15, 2011, at 12:18 PM, Michael Barton wrote: William, Are the missing API's a problem for GRASS? Can you get a GRASS/terminal/wxGUI terminal error message? The one from Apple is less helpful. But if that is the only one you have, can you send it? I wonder if it is a 64bit compilation issue? Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Aug 13, 2011, at 12:25 PM, William Kyngesburye wrote: This is now a real problem - wxpython 2.8.x series will not compile on OS X Lion. Lion appears to have the remaining pure-Carbon bits removed (that wxpython 2.8 needs). I think it's really only a problem for OpenGL - that's where I get compile errors in wxPython, the GUI seems to run with a wxPython compiled on earlier
Re: [GRASS-dev] OS X Lion: wxpython 2.9
org.python is just the standard id for python, nothing to do with whether it's the system Python or not. Only system Python for me. On Aug 17, 2011, at 6:55 PM, Michael Barton wrote: There are a bunch of 'org.python.org' messages. This doesn't refer to a python.org install somewhere does it? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] OS X Lion: wxpython 2.9
This is now a real problem - wxpython 2.8.x series will not compile on OS X Lion. Lion appears to have the remaining pure-Carbon bits removed (that wxpython 2.8 needs). I think it's really only a problem for OpenGL - that's where I get compile errors in wxPython, the GUI seems to run with a wxPython compiled on earlier system versions (and I don't run into OpenGL because wxnviz is not enabled for GRASS 6.4). The 2.9 dev series has a cocoa option now, but 2.9 is in development. Nice bonus: it's now finally 64bit. But there are some issues yet to work out. A couple APIs were deprecated in OSX 10.6 and removed in 10.7, and so far no definite solution is in the wxPython code. The only options then are (to be able to use wx 2.9 cocoa where OpenGL is usable) - to compile for the 10.6 SDK, thus the system Python 2.6 - to compile for the 10.6 SDK with python.org (or other) Python 2.7 (if python 2.7 is wanted) There is a downloadable wxpython 2.9 cocoa from wxpython.org, that is built for 64bit python 2.7 on OSX 10.5+, but the GUI crashes on startup with this. I can't tell if it's a GRASS problem, I can copy the crash report to list if anyone's interested (it's a long stack trace), or start a bug report, but I don't have time to poke around with it much. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Time is an illusion - lunchtime doubly so. - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] odd configure error on MacOS X
On Jul 29, 2011, at 3:41 AM, Dylan Beaudette wrote: It seems more complicated that I thought. After fixing the includes, to use the KingChaos Frameworks, recompiling results in: In file included from Graph.c:19: /Library/Frameworks/cairo.framework/unix/include/cairo/cairo-svg.h:79:3: error: #error Cairo was not compiled with support for the svg backend make: *** [OBJ.i386-apple-darwin9.8.0/Graph.o] Error 1 Can SVG be disabled somehow? Dylan Odd, my cairo framework svg support. cairo-features.h has: #define CAIRO_HAS_SVG_SURFACE 1 FYI, I configure GRASS for my cairo framework with (note the *2* include dirs): --with-cairo --with-cairo-includes=/Library/Frameworks/cairo.framework/unix/include/cairo /Library/Frameworks/cairo.framework/unix/include --with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib --with-cairo-ldflags=-lcairo \ - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-user] g.extension and GRASS 6.4.1
On May 15, 2011, at 6:11 AM, Hamish wrote: Hamish: finally we should consider what happens on Ubuntu and possibly OSX where by default there is no root pw sudo is used; William: I'm not sure what you mean. I've never had any problems running sudo, either directly in the terminal or from a script. It *always* asks for a password and you type in your login (admin) password, and it doesn't matter that root has a null password. I was talking about the -s flag which runs su -c make ... install I don't remember if I notified the list or not, but I've now added a -u flag to run sudo make ... install instead, for those systems which need it. so have you been running sudo g.extension ... ? No, i meant sudo for other things. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Those people who most want to rule people are, ipso-facto, those least suited to do it. - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-user] g.extension and GRASS 6.4.1
On May 13, 2011, at 4:39 AM, Hamish wrote: wrt when GRASS_ADDON_PATH contains multiple entries, in r46257,8 I've set it to just take the first one. Mac-- William: would it be better to grab the last one? WinGrass-- will the MSYS path ever contain C:\ ? The user path is first, I think that's reasonable to default to finally we should consider what happens on Ubuntu and possibly OSX where by default there is no root pw sudo is used; I'm not sure what you mean. I've never had any problems running sudo, either directly in the terminal or from a script. It *always* asks for a password and you type in your login (admin) password, and it doesn't matter that root has a null password. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] R/GRASS GIS issue with rgdal
My rgdal package is made for R 2.12, as it says. Though the R installer may let you install it anyways, it is linked to the R 2.12 framework. I don't know why it loaded from the Terminal. It should have the same linking error. Anyways, looks like I missed an R update. I need to package a new rgdal for R 2.13 ;) Watch for it on my frameworks page... On Apr 30, 2011, at 6:52 PM, Thomas Adams wrote: All: Sorry for posting the way I have, but I am not really sure where to send this, as it is NOT a GRASS issue, really, but… On a Mac running OS X 10.6.7, I have the following issue: (1) I've loaded the GRASS GRASS-6.4.1-1-Snow.dmg from the KyngChaos Wiki (2) GDAL Complete 1.8 framework package (3) rgdal 0.6.33-1 - R 2.12 package (4) installed R 2.13 Mac binary from CRAN The curious thing is, if I try to load rgdal through the Mac R GUI, I get: library(rgdal) Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared object '/Library/Frameworks/R.framework/Versions/2.13/Resources/library/rgdal/libs/i386/rgdal.so': dlopen(/Library/Frameworks/R.framework/Versions/2.13/Resources/library/rgdal/libs/i386/rgdal.so, 6): Library not loaded: /Library/Frameworks/R.framework/Versions/2.12/Resources/lib/libR.dylib Referenced from: /Library/Frameworks/R.framework/Versions/2.13/Resources/library/rgdal/libs/i386/rgdal.so Reason: image not found Error: package/namespace load failed for 'rgdal' However, if I load rgdal in R through a Mac term window R prompt, life is good and I get: library(rgdal) Loading required package: sp Geospatial Data Abstraction Library extensions to R successfully loaded Loaded GDAL runtime: GDAL 1.8.0, released 2011/01/12 Path to GDAL shared files: /Library/Frameworks/GDAL.framework/Versions/1.8/Resources/gdal Loaded PROJ.4 runtime: Rel. 4.7.1, 23 September 2009 Path to PROJ.4 shared files: (autodetected) Now, I would -only- do GRASS/R stuff through the GRASS R term window command line prompt anyway, but I find this difference perplexing. Any thoughts? Regards, Tom -- Thomas E Adams National Weather Service Ohio River Forecast Center 1901 South State Route 134 Wilmington, OH 45177 EMAIL:thomas.ad...@noaa.gov VOICE:937-383-0528 FAX: 937-383-0033 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Warning to Mac users: TclTk 8.5.9 breaks compatibility for NVIZ
Don't upgrade to TclTk 8.5.9, stick with 8.5.8. I realize it's been out since last September, but I never upgraded out of laziness and didn't notice. They switched to use the system Cocoa API from the old Carbon API (should have saved that for 8.6). Togl still has Carbon calls in it, and I don't think that'll change (it's not an easy fix, and GRASS still uses the older togl 1.7, and even 2.0 still uses Carbon). I'm too lazy to report a bug for TclTk on this - I don't use NVIZ and expect GRASS 7 (and maybe 6) to eventually have something working in Python anyways. Unfortunately, ActiveState, that makes the ActiveTcl that is recommended for compilation and my binaries, only provides old versions for download for the business edition, and doesn't allow reditribution of their installers. I'll have to restore the TclTk compile instructions in the Mac readme in the GRASS source, and figure out something to make a TclTk 8.5.8 available for existing GRASS packages. Any user-compiled or other distribution of TclTk 8.5.8 Aqua frameworks should work, as it's all just standard options in the source. Note: this only affects NVIZ. TclTk GUI is not affected. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] recent updates to Vlib break vectors in GRASS 7
Try it now. On Jan 2, 2011, at 6:16 PM, Barton Michael wrote: Will this be difficult to fix? Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 29, 2010, at 4:32 PM, Glynn Clements wrote: William Kyngesburye wrote: I suspect it's because r44722 added gprojects.h to Vlib, in particular that open_ogr.c where Michael got the error. Erm, yeah. That's sounds like the most likely explanation. There are a lot sources in vlib, so I didn't check if any others included gprojects.h indirectly. So, the question then: add PROJINC to VECT_CFLAGS (for all vector stuff) or to the vlib makefile only? Vlib/Makefile only. The reason for VECT_CFLAGS is that vector.h includes geos_c.h and vect/dig_structs.h includes ogr_api.h, so *anything* which uses those headers needs the appropriate -I switches or an error will occur, even if the module doesn't actually use the structure or function declarations which use the OGR/GEOS types. But simply including the vector headers doesn't pull in the PROJ headers, so there's no need for VECT_CFLAGS to contain $(PROJINC). Ideally, -I switches (and to a lesser extent, -L switches) should be kept to a minimum; the more directories in a search path, the greater the chance of encountering conflicting file names. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] recent updates to Vlib break vectors in GRASS 7
On Dec 28, 2010, at 10:33 PM, Glynn Clements wrote: William Kyngesburye wrote: It's VECT_INC and is set in one of the makefile fragments, I think. It used to be all in grass.make. Glynn's the master of all that makefile magic. VECT_INC has been empty for a long time now, and it never contained $(PROJINC) directly or indirectly. It was first added to Grass.make.in in r11189 on 2003-02-27, at which time it had the value $(PQINCPATH). It stayed that way until r12781 on 2004-05-21, when it became empty. And it has been empty ever since. Any code which uses PROJ headers should be using $(PROJINC). You may be thinking of VECT_CFLAGS, which is defined as: VECT_CFLAGS = $(GDALCFLAGS) $(GEOSCFLAGS) FWIW, I suspect that this issue may have been hidden in the past due to gdal-config --cflags providing the necessary switches. GDAL itself uses PROJ, although its headers don't require the PROJ headers. gdal-config has never returned the PROJ inc flag as far as I can tell, at least for the OSX framework. I suspect it's because r44722 added gprojects.h to Vlib, in particular that open_ogr.c where Michael got the error. There are a lot sources in vlib, so I didn't check if any others included gprojects.h indirectly. So, the question then: add PROJINC to VECT_CFLAGS (for all vector stuff) or to the vlib makefile only? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] recent updates to Vlib break vectors in GRASS 7
On Dec 28, 2010, at 1:20 AM, Markus Neteler wrote: On Tue, Dec 28, 2010 at 6:51 AM, Hamish hamis...@yahoo.com wrote: Michael wrote: gcc -g -O2 -arch i386 -arch x86_64 -fno-common -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -D_FILE_OFFSET_BITS=64 -I/Library/Frameworks/GDAL.framework/Versions/1.7/Headers -I/Library/Frameworks/GEOS.framework/Versions/3/unix/include -DPACKAGE=\grasslibs\ -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -o OBJ.i386-apple-darwin10.5.0/open_ogr.o -c open_ogr.c In file included from open_ogr.c:26: /Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include/grass/gprojects.h:21:22: error: proj_api.h: No such file or directory it's not finding the proj4 includes. On Linux 64bit I have no problems to compile. It needs the PROJ include dir in the compile command. It'll work on Linux since all includes are in /usr/[local/]include. On OS X it's a separate PROJ framework. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Those people who most want to rule people are, ipso-facto, those least suited to do it. - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] recent updates to Vlib break vectors in GRASS 7
It's VECT_INC and is set in one of the makefile fragments, I think. It used to be all in grass.make. Glynn's the master of all that makefile magic. On Dec 28, 2010, at 8:36 AM, Barton Michael wrote: Thanks for finding the problem William. How can this be fixed? Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 28, 2010, at 7:29 AM, William Kyngesburye wrote: On Dec 28, 2010, at 1:20 AM, Markus Neteler wrote: On Tue, Dec 28, 2010 at 6:51 AM, Hamish hamis...@yahoo.com wrote: Michael wrote: gcc -g -O2 -arch i386 -arch x86_64 -fno-common -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -D_FILE_OFFSET_BITS=64 -I/Library/Frameworks/GDAL.framework/Versions/1.7/Headers -I/Library/Frameworks/GEOS.framework/Versions/3/unix/include -DPACKAGE=\grasslibs\ -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -I/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include -o OBJ.i386-apple-darwin10.5.0/open_ogr.o -c open_ogr.c In file included from open_ogr.c:26: /Users/Shared/grass_dev/grass70_dev/dist.i386-apple-darwin10.5.0/include/grass/gprojects.h:21:22: error: proj_api.h: No such file or directory it's not finding the proj4 includes. On Linux 64bit I have no problems to compile. It needs the PROJ include dir in the compile command. It'll work on Linux since all includes are in /usr/[local/]include. On OS X it's a separate PROJ framework. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Those people who most want to rule people are, ipso-facto, those least suited to do it. - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS for Mac problem
On Sep 27, 2010, at 2:13 PM, Michael Barton wrote: '/Users/kierstincatlett/Desktop/GRASS-7.0.app/Contents/MacOS/grass.sh'; exit macintosh-159:~ kierstincatlett$ '/Users/kierstincatlett/Desktop/GRASS-7.0.app/Contents/MacOS/grass.sh'; exit Rebuilding Addon HTML manual pages index... Rebuilding Addon menu... 2010-09-16 10:10:54.809 osascript[5254:903] Error loading /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: dlopen(/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types, 262): no suitable image found. Did find: /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: no matching architecture in universal wrapper osascript: OpenScripting.framework - scripting addition /Library/ScriptingAdditions/Adobe Unit Types.osax declares no loadable handlers. Python 2.6.1 found. Cleaning up temporary files... Traceback (most recent call last): File /Users/kierstincatlett/Desktop/GRASS-7.0.app/Contents/MacOS/grass70, line 938, in module clean_temp() File /Users/kierstincatlett/Desktop/GRASS-7.0.app/Contents/MacOS/grass70, line 799, in clean_temp call([gfile(etc, clean_temp)], stdout = nul, stderr = nul) File /Users/kierstincatlett/Desktop/GRASS-7.0.app/Contents/MacOS/grass70, line 105, in call return subprocess.call(cmd, **kwargs) File /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/subprocess.py, line 444, in call File /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/subprocess.py, line 595, in __init__ File /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/subprocess.py, line 1106, in _execute_child OSError: [Errno 2] No such file or directory logout [Process completed] grass etc/clean_temp? My last 7.0 build from June has this. clean_temp() is a method defined in grass70. It uses another method in grass70, call() call() is just a shortcut to subprocess.call(), which is standard python syntax, with some options for windows user. The error that subprocess.call() does not exist is bogus, since Kirsten has the standard Python 2.5.1 and 2.6 installations that come with Mac OS X 10.6. GRASS 6.4 works fine for her with the wxpython interface. So it isn't a corruption of her python installation. But I can't figure out what is generating this error. Right. clean_temp(), the function, is using call() to run etc/clean_temp, the program. clean_temp, the program, is what I think it's complaining that it can't find. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GUI 64-bit issues
On Sep 23, 2010, at 6:29 PM, Jeshua Lacock wrote: This is taken care of in the Mac app build with a python wrapper. The wrapper is seen as a single word, thus the GUI run commands are happy. If you don't use the builtin Mac app build option, you won't get this wrapper (I thought about moving it into the general lib/init stuff so it's available to all Mac builds, but I either had a problem with that or got distracted). Thanks William, Just setting the environment variable does it for me: export VERSIONER_PYTHON_PREFER_32_BIT=yes That's the one. If it works, it's possible I avoided it because I didn't want to rely on an Apple hack. It doesn't work with the python.org Pythons (last I checked). - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GUI 64-bit issues
On Sep 23, 2010, at 10:19 PM, Jeshua Lacock wrote: On Sep 23, 2010, at 9:04 PM, William Kyngesburye wrote: On Sep 23, 2010, at 6:29 PM, Jeshua Lacock wrote: This is taken care of in the Mac app build with a python wrapper. The wrapper is seen as a single word, thus the GUI run commands are happy. If you don't use the builtin Mac app build option, you won't get this wrapper (I thought about moving it into the general lib/init stuff so it's available to all Mac builds, but I either had a problem with that or got distracted). Just setting the environment variable does it for me: export VERSIONER_PYTHON_PREFER_32_BIT=yes That's the one. If it works, it's possible I avoided it because I didn't want to rely on an Apple hack. It doesn't work with the python.org Pythons (last I checked). On a related note, I only have the 2D view option available - is tcltk required for the 3D view? I was under the impression wxPython had a 3D view now... wx nviz and wx vdigit were disabled in the 6.4 release because they are not finished and had problems. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.external and GDAL linking
I just tried r.external for the first time, and while r.external successfully created the link raster, any attempt to access the raster data results in the error Unable to load GDAL library. Looking at where that error comes from, I find lib/gis/gdal.c, where it's trying to dynamically load the GDAL library. Looks like it's hardwired that way in the lib/gis makefile: GDAL_DYNAMIC = 1 Is it safe to override this, so that libgis static-links GDAL? It looks like the makefile and gdal.c are setup to toggle such static linking. Shouldn't there be a configure option for this (assuming it works)? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Mac package is ready. On Sep 3, 2010, at 3:55 PM, Markus Neteler wrote: Done and done :) Once the relevant binaries are online, we can post the big announcement and upload the updated rss.xml for the news box. cheers Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Aug 24, 2010, at 7:55 AM, Hamish wrote: Markus wrote: Please change the default GUI and I'll prepare RC7 then immediately. release summary now prepared from svn log: https://trac.osgeo.org/grass/wiki/Release/6.4.0RC7-News (except for final details of course..) clean as needed, enjoy the new trac wiki edit-by-section, just click on the hidden [edit] to the right of each section heading. e.g. I'm sure r.watershed: upgraded to improved version and r.out.gdal improvements could be better explained. Hamish I updated the Mac startup so it should let init.sh set the default. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxnviz on mac osx (grass7.0)
That's the TclTk NVIZ. And it looks like it's configured for the system TclTk (8.5). I tried that a while back when Snow Leopard came out - updated tcltk, 64bits - but had problems compiling, it might have been the same error. You need to install TclTk 8.5 from ActiveState and configure for that. See the Mac compile readme in the source. On Aug 19, 2010, at 6:42 AM, Massimo Di Stefano wrote: Hi, problems to get wx-nviz running on mac osx 10.6.4 building grass7.0 this the log : Finished compilation: Gio 19 Ago 2010 13:31:39 CEST make: *** [default] Error 1 MacBook-Pro-15-di-sasha:grass_trunk sasha$ cd /Users/sasha/gis/grass_trunk/visualization/nviz MacBook-Pro-15-di-sasha:nviz sasha$ make make -C src gcc -g -O2-arch i386 -arch x86_64 -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -D_FILE_OFFSET_BITS=64 -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Library/Frameworks/UnixImageIO.framework/unix/include -I/Library/Frameworks/GDAL.framework/Versions/1.7/Headers -I/Library/Frameworks/GEOS.framework/Versions/3/unix/include -DPACKAGE=\grassmods\ -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -o OBJ.i386-apple-darwin10.4.0/togl.o -c togl.c In file included from togl.c:53: /usr/include/tkMacOSX.h:31: error: expected declaration specifiers or ‘...’ before ‘TkRegion’ togl.c:54:54: error: tkMacOSXInt.h: No such file or directory togl.c:265: error: expected specifier-qualifier-list before ‘XVisualInfo’ togl.c: In function ‘SetMacBufRect’: ... - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxnviz on mac osx (grass7.0)
On Aug 19, 2010, at 9:36 AM, Massimo Di Stefano wrote: Hi William, right :-) thanks to point me to tcltk i'm on a fresh osx installation .. so i'll rebuild tcltk for both 32+64 bit and reconfigure grass. Just stick with the ActiveState TclTk install. Last I tried to build TclTk 8.5.8 64bit, it didn't work. ActiveState seems to be the 'official' build, and even they don't build 64bit. Tcltk 8.6 is still in beta, and I don't know if 64bit status has improved or if it works in GRASS. but this error wil be not related to the wx-nviz crash, is it right ? i have a wxniz crash on both grass 6.5 and 7.0. Could be something to do with running nviz from inside the GUI. To see if NVIZ itself is OK, just run it from the GRASS terminal. i'll update my tcltk and try again, thanks! Massimo. Il giorno 19/ago/2010, alle ore 16.30, William Kyngesburye ha scritto: That's the TclTk NVIZ. And it looks like it's configured for the system TclTk (8.5). I tried that a while back when Snow Leopard came out - updated tcltk, 64bits - but had problems compiling, it might have been the same error. You need to install TclTk 8.5 from ActiveState and configure for that. See the Mac compile readme in the source. - 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-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
I'll follow whatever is decided. I probably don't need to set a default GRASS_GUI in the Mac startup (just let init.sh handle the default), except that I do need to make *some* assumption about a setting to work around an application focus issue in OSX Tiger. I'll see if I can figure out a less intrusive test for the GUI setting. On Aug 18, 2010, at 1:58 PM, Helena Mitasova wrote: as Hamish has noted the choice of the default GUI is decided by whoever does the binary package (?). So my plea was pretty much for William to make wxGUI default in his Mac binary. People who run linux or compile GRASS from source are generally used to customizing so that is not so much an issue. It is really for newcomers who download GRASS binary and start GRASS and then the first thing they have to deal with is to change GUI. The biggest issue that the newcomers had with the TclTk GUI (and that was solved in wxGUI) was - why the map is not displayed when I load it into gis manager? All of this made starting with GRASS on Mac unexpectedly more difficult than on MSWindows. At this point our semester has already started so I will have to deal with it , and if I understand the process correctly, 6.4 can be released with TclTk as default but with MSW and Mac binaries packaged with wxGUI as default. Of course, I would much prefer if the release was with wxGUI as default. I don't have enough expertise on ctypes but we have troubles with it on our enterprise linux when compiling, but that is just a local problem, Helena - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass65 compilation on mac OSX
On Aug 7, 2010, at 10:50 AM, Helena Mitasova wrote: William, thanks for the hint for compilation of grass7, it worked. Now I am trying to compile from source also 6.5 and everything runs except the old nviz - I am getting similar error: Undefined symbols for architecture x86_64: _GetPortBounds, referenced from: _SetMacBufRect in togl.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/-w/-wN910nTFamsDLR+fBkvBTI/-Tmp-//cc1B1KT1.out (No such file or directory) make[1]: *** [/Users/helena/grassdev6/develbranch_6/dist.i386-apple-darwin10.2.0/bin/nviz] Error 1 make: *** [default] Error 2 That would be something from TclTk, which is not working for 64bits on OS X. Odd, configure should disable 64bit for NVIZ compilation. There is a var you can check, in include/make/platform.make: MACOSX_ARCHS_TCLTK It should have only --arch i386. --enable-64bit \ Note: enable-64bit does nothing for OS X. 64bit compilation is handled with the macosx-archs option. (it shouldn't be affecting your problem, just FYI) --with-python=/usr/bin/python-config \ --with-wxwidgets=/usr/bin/wx-config \ FYI: the system wxpython is getting a bit old for some things in new GRASS gui. (python itself is OK) --with-tcltk-includes=/Library/Frameworks/Tcl.framework/Headers /Library/Frameworks/Tk.framework/Headers /Library/Frameworks/Tk.framework/PrivateHeaders \ --with-opengl=aqua \ Which version of TclTk did you install? I think 8.5 is optimal. Also, there's a bit of a hack needed so the system tcltk doesn't interfere, see the macosx/readme.rtf in the GRASS source for details. Then add --with-tcltk-libs=/usr/local/lib to your configure. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Jul 26, 2010, at 2:39 PM, Markus Metz wrote: Markus Neteler wrote: the two (!) remaining blocker bugs are: * https://trac.osgeo.org/grass/ticket/1115 - Mac OSX only? Seems to be a wxpython 2.8.10.1 problem (wasn't there something similar recently in the new i.points?) Not related to the problem the new i.points had with wxpython 2.8.7, unfortunately, otherwise I could have had an idea. I looked into #1115 but have no idea why it fails, same wx version but different python version, so it's apparently not wx but python. Cleared up, bad wx build. Sorry for the holdup. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
