date:20151008

Re: [GRASS-dev] wx.metadata ready for testing

2015-10-08 Thread Paulo van Breugel




On 07-10-15 22:29, Martin Landa wrote:

Hi,

2015-10-07 12:30 GMT+02:00 Paulo van Breugel :

I tried fresh installation (trunk) in installed to /usr/local. I
cannot reproduce any of reported errors. Please send me related
environmental variables:

env | grep GIS

env | grep GRASS


Hi Martin, here they are:

GRASS 7.1.svn (Data_latlon):~ > env | grep GIS

GISRC=/tmp/grass7-paulo-13351/gisrc

GISBASE=/usr/local/grass7/grass-7.1.svn

GIS_LOCK=13351

GRASS 7.1.svn (Data_latlon):~ > env | grep GRASS

GRASS_PYTHON=python

GRASS_GNUPLOT=gnuplot -persist

GRASS_PAGER=more

GRASS_PROJSHARE=/usr/share/proj

GRASS_VERSION=7.1.svn

GRASS_HTML_BROWSER=xdg-open

GRASS_ADDON_BASE=/home/paulo/.grass7/addons

HISTFILE=/media/HD2/Data/GRASSdb/Data_latlon/VECEA_species/.bash_history






?

Ma


ware/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata

/usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory

`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'

if [ "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata" != "" ] ;
then
GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71
GISBASE=/usr/local/grass7/grass-7.1.svn

PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH"

PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH"

LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
LC_ALL=C /usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata
--html-description < /dev/null | grep -v '\|' >
g.gui.metadata.tmp.html ; fi

Traceback (most recent call last):

   File "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata", line
35, in


 import mdgrass

ImportError: No module named mdgrass

make[1]: *** [g.gui.metadata.tmp.html] Error 1

rm g.gui.metadata.tmp.html

make[1]: Leaving directory

`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'






--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa







___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

2015-10-08 Thread GRASS GIS

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc 
speed
--+---
  Reporter:  sprice   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.1.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---

Comment (by wenzeslaus):

 Replying to [comment:6 wenzeslaus]:
 > Replying to [comment:5 sprice]:
 > > I just uploaded a new version of the code that shouldn't fail any
 additional unit tests, and I've added unit tests to r.compress that test
 reading/writing the different compression schemes.
 >
 > Nice. Runs for me as well.

 Bad news. Only the r.compress tests runs well for me. I messed up the
 environmental variables.

 Now (with `export GRASS_INT_LZ4=1`) I'm getting fails from various tests.

 Wrong values in the result (for example):

 {{{
 ./raster/r.series.interp/testsuite/interp_test.py
 ==
 FAIL: test_infile (__main__.InterpolationTest)
 --
 AssertionError: The actual maximum (269) is greater than the reference
 one (200) for raster map prec_2 (with minimum 200)
 }}}

 Possible segmentation faults:

 {{{
 ./raster/r.gwflow/testsuite/validation_7x7_grid.py
 =
 FAIL: test_transient (__main__.Validation7x7Grid)
 -
 AssertionError: Running  module ended with non-zero return code
 (-11)
 }}}

 {{{
 ./temporal/t.rast.univar/testsuite/test.t.rast.univar.sh
 ...
 grass.exceptions.CalledModuleError: Module run ['r.univar', '-ge',
 u'map=prec_1@__temporal_t_rast_univar_test.t. rast.univar'] ended with
 error
 Process ended with non-zero return code -11.
 }}}

 With the changes applied but with default settings (`unset
 GRASS_INT_LZ4`), I'm getting the same results as at the
 
[http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-10-08-07-00/report_for_nc_basic_spm_grass7_nc/testfiles.html
 test server]. r.compress test runs well in both cases.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.stream.watersheds & r.stream.variables add-on

2015-10-08 Thread Giuseppe Amatulli

Hi,
we have developed 2 grass add-on

"r.stream.watersheds" that performs (for each single grid cell of a stream
network) the sub-watershed delineation based on the drainage direction and
a gridded stream network


"r.stream.variables" which will calculate and relate the
upstream-contributing environmental conditions (contiguous layers, e.g.
air-temperature, elevation, land use, etc.) to each stream grid cell.
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.stream.variables

The main output is thus an environmental variable that follows the river
continuum from the source to the mouth of a river, and can be used in e.g.
species distribution models (or any ecological model).
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.stream.watersheds

A publication has been submitted and will be soon on line.

Right now the add-on is in Bash ( it was easier to adapt the same script
that we use in the high-performace-computing for the massive computation)
but we are planing to translate in  python.

While converting the add-ons into python, we want to provide users the
possibility to use these tools. We would like to fill in the manual
page, and provide a short-term work-around (copy the .sh-files into
/scripts, as this works perfectly).

Meanwhile, we work on the python version and release it as soon as
possible. Does this sound reasonable?

Is there a way we could have the manual page for these add-ons online?

Thanks and best wishes,
Giuseppe & Sami




-- 
Giuseppe Amatulli, Ph.D.

Department of Ecology and Evolutionary Biology, Yale University.
Jetz Lab, OML Room 405

P.O. Box 208106
165 PROSPECT ST
New Haven, CT 06520-8106
Teaching: spatial-ecology.net
Work:  http://sbsc.yale.edu/giuseppe-amatulli

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Michael Barton

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:

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

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

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Anna Petrášová

On Thu, Oct 8, 2015 at 5:24 PM, Michael Barton 
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

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Michael Barton

I could try that. I originally build liblas with dual architecture. But current 
OS X and boost choke on dual architecture. So I built it 64 bit. I assumed that 
that means I needed to build laslib also only 64 bit. If you think I can get 
away with dual architecture there, I can give it a try.

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 4:07 PM, Anna Petrášová 
> wrote:



On Thu, Oct 8, 2015 at 6:26 PM, Michael Barton 
> wrote:
I built boost with both bjam and b2 for i86_64. Here are the setups I used:

cd /Users/Shared/grass_dev/boost_1_59_0
edit 
/Users/cmbarton/grass_source/LAS/boost_1_59_0/tools/build/src/tools/darwin.jam 
to delete -gdwarf-2 ]

export CXXFLAGS=-stdlib=libstdc++
./bootstrap.sh --prefix=/Users/cmbarton/grass_source/LAS/boostlib 
--without-libraries=python

## attempt 1
./bjam variant=release link=static --without-mpi -j4 macosx-version=10.7 
macosx-version-min=10.7 architecture=x86 address-model=64 install

## attempt 2
./b2 variant=release link=static --without-mpi -j4 macosx-version=10.7 
macosx-version-min=10.7 cxxflags="-arch x86_64"

I built liblas for i86_64. I initially set the prefix to put all the liblas 
files into a local directory where I could get them for packaging. Then I did 
it again letting them go into /usr/local. In all cases I get this same error. 
This is with installing it into a nice local folder.

xport BOOST_ROOT="/Users/cmbarton/grass_source/LAS/boostlib"
export BOOST_INCLUDEDIR="/Users/cmbarton/grass_source/LAS/boostlib/include"

cmake -G "Unix Makefiles" \
-D CMAKE_INSTALL_PREFIX="/Users/cmbarton/grass_source/LAS/liblasdist" \
-D CMAKE_OSX_ARCHITECTURES="x86_64"  \
-D CMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.7.sdk" \
-D GDAL_CONFIG="/Library/Frameworks/GDAL.framework/Programs/gdal-config" \
-D GDAL_INCLUDE_DIR="/Library/Frameworks/GDAL.framework/Headers" \
-D GDAL_LIBRARY="/Library/Frameworks/GDAL.framework/unix/lib/libgdal.dylib" \
-D GEOTIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/unix/include" 
 \
-D 
GEOTIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib"
  \
-D TIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/Headers" \
-D 
TIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libtiff.dylib" 
\
-D CMAKE_VERBOSE_MAKEFILE=true ../


Here is the GRASS configure error:

1 warning generated.
configure:6164: checking whether to use libLAS
configure:6181: checking for liblas-config
configure:6238: gcc -o conftest -g -O2   -arch i386 -arch x86_64 -isysroot 
/Developer/SDKs/MacOSX10.7.sdk-I/usr/local/include -I/usr/local/include 
-I/Library/Frameworks/GDAL.framework/Headers 
-I/Library/Frameworks/UnixImageIO.framework/unix/include 
-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

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Anna Petrášová

On Thu, Oct 8, 2015 at 6:26 PM, Michael Barton 
wrote:

> I built boost with both bjam and b2 for i86_64. Here are the setups I
> used:
>
> cd /Users/Shared/grass_dev/boost_1_59_0
> edit
> /Users/cmbarton/grass_source/LAS/boost_1_59_0/tools/build/src/tools/darwin.jam
> to delete -gdwarf-2 ]
>
> export CXXFLAGS=-stdlib=libstdc++
> ./bootstrap.sh --prefix=/Users/cmbarton/grass_source/LAS/boostlib
> --without-libraries=python
>
> ## attempt 1
> ./bjam variant=release link=static --without-mpi -j4 macosx-version=10.7
> macosx-version-min=10.7 architecture=x86 address-model=64 install
>
> ## attempt 2
> ./b2 variant=release link=static --without-mpi -j4 macosx-version=10.7
> macosx-version-min=10.7 cxxflags="-arch x86_64"
>
> I built liblas for i86_64. I initially set the prefix to put all the
> liblas files into a local directory where I could get them for packaging.
> Then I did it again letting them go into /usr/local. In all cases I get
> this same error. This is with installing it into a nice local folder.
>
> xport BOOST_ROOT="/Users/cmbarton/grass_source/LAS/boostlib"
> export BOOST_INCLUDEDIR="/Users/cmbarton/grass_source/LAS/boostlib/include"
>
> cmake -G "Unix Makefiles" \
> -D CMAKE_INSTALL_PREFIX="/Users/cmbarton/grass_source/LAS/liblasdist" \
> -D CMAKE_OSX_ARCHITECTURES="x86_64"  \
> -D CMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.7.sdk" \
> -D GDAL_CONFIG="/Library/Frameworks/GDAL.framework/Programs/gdal-config" \
> -D GDAL_INCLUDE_DIR="/Library/Frameworks/GDAL.framework/Headers" \
> -D
> GDAL_LIBRARY="/Library/Frameworks/GDAL.framework/unix/lib/libgdal.dylib" \
> -D
> GEOTIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/unix/include"
>  \
> -D
> GEOTIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib"
>  \
> -D TIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/Headers" \
> -D
> TIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libtiff.dylib"
> \
> -D CMAKE_VERBOSE_MAKEFILE=true ../
>
>
> Here is the GRASS configure error:
>
> 1 warning generated.
> configure:6164: checking whether to use libLAS
> configure:6181: checking for liblas-config
> configure:6238: gcc -o conftest -g -O2   -arch i386 -arch x86_64 -isysroot
> /Developer/SDKs/MacOSX10.7.sdk-I/usr/local/include -I/usr/local/include
> -I/Library/Frameworks/GDAL.framework/Headers
> -I/Library/Frameworks/UnixImageIO.framework/unix/include
> -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
>
>
>
>

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Michael Barton

I built boost with both bjam and b2 for i86_64. Here are the setups I used:

cd /Users/Shared/grass_dev/boost_1_59_0
edit 
/Users/cmbarton/grass_source/LAS/boost_1_59_0/tools/build/src/tools/darwin.jam 
to delete -gdwarf-2 ]

export CXXFLAGS=-stdlib=libstdc++
./bootstrap.sh --prefix=/Users/cmbarton/grass_source/LAS/boostlib 
--without-libraries=python

## attempt 1
./bjam variant=release link=static --without-mpi -j4 macosx-version=10.7 
macosx-version-min=10.7 architecture=x86 address-model=64 install

## attempt 2
./b2 variant=release link=static --without-mpi -j4 macosx-version=10.7 
macosx-version-min=10.7 cxxflags="-arch x86_64"

I built liblas for i86_64. I initially set the prefix to put all the liblas 
files into a local directory where I could get them for packaging. Then I did 
it again letting them go into /usr/local. In all cases I get this same error. 
This is with installing it into a nice local folder.

xport BOOST_ROOT="/Users/cmbarton/grass_source/LAS/boostlib"
export BOOST_INCLUDEDIR="/Users/cmbarton/grass_source/LAS/boostlib/include"

cmake -G "Unix Makefiles" \
-D CMAKE_INSTALL_PREFIX="/Users/cmbarton/grass_source/LAS/liblasdist" \
-D CMAKE_OSX_ARCHITECTURES="x86_64"  \
-D CMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.7.sdk" \
-D GDAL_CONFIG="/Library/Frameworks/GDAL.framework/Programs/gdal-config" \
-D GDAL_INCLUDE_DIR="/Library/Frameworks/GDAL.framework/Headers" \
-D GDAL_LIBRARY="/Library/Frameworks/GDAL.framework/unix/lib/libgdal.dylib" \
-D GEOTIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/unix/include" 
 \
-D 
GEOTIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib"
  \
-D TIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/Headers" \
-D 
TIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libtiff.dylib" 
\
-D CMAKE_VERBOSE_MAKEFILE=true ../


Here is the GRASS configure error:

1 warning generated.
configure:6164: checking whether to use libLAS
configure:6181: checking for liblas-config
configure:6238: gcc -o conftest -g -O2   -arch i386 -arch x86_64 -isysroot 
/Developer/SDKs/MacOSX10.7.sdk-I/usr/local/include -I/usr/local/include 
-I/Library/Frameworks/GDAL.framework/Headers 
-I/Library/Frameworks/UnixImageIO.framework/unix/include 
-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.

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á 
> wrote:



On Thu, Oct 8, 2015 at 5:24 PM, Michael Barton 
> 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

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Anna Petrášová

On Thu, Oct 8, 2015 at 7:33 PM, Michael Barton 
wrote:

> I could try that. I originally build liblas with dual architecture. But
> current OS X and boost choke on dual architecture. So I built it 64 bit. I
> assumed that that means I needed to build laslib also only 64 bit. If you
> think I can get away with dual architecture there, I can give it a try.
>

I don't know if it helps, I just assumed this could be the problem since it
complaint about  " file was built for archive which is not the architecture
being linked (i386)". In the GRASS configure, you specify i386 and x86_64,
but it can't find the i386 liblas. You can try changing GRASS configure to
use only x86_64. But I have very vague understanding of how these things
work, so I hope someone else could help.


> 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 4:07 PM, Anna Petrášová  wrote:
>
>
>
> On Thu, Oct 8, 2015 at 6:26 PM, Michael Barton 
> wrote:
>
>> I built boost with both bjam and b2 for i86_64. Here are the setups I
>> used:
>>
>> cd /Users/Shared/grass_dev/boost_1_59_0
>> edit
>> /Users/cmbarton/grass_source/LAS/boost_1_59_0/tools/build/src/tools/darwin.jam
>> to delete -gdwarf-2 ]
>>
>> export CXXFLAGS=-stdlib=libstdc++
>> ./bootstrap.sh --prefix=/Users/cmbarton/grass_source/LAS/boostlib
>> --without-libraries=python
>>
>> ## attempt 1
>> ./bjam variant=release link=static --without-mpi -j4 macosx-version=10.7
>> macosx-version-min=10.7 architecture=x86 address-model=64 install
>>
>> ## attempt 2
>> ./b2 variant=release link=static --without-mpi -j4 macosx-version=10.7
>> macosx-version-min=10.7 cxxflags="-arch x86_64"
>>
>> I built liblas for i86_64. I initially set the prefix to put all the
>> liblas files into a local directory where I could get them for packaging.
>> Then I did it again letting them go into /usr/local. In all cases I get
>> this same error. This is with installing it into a nice local folder.
>>
>> xport BOOST_ROOT="/Users/cmbarton/grass_source/LAS/boostlib"
>> export
>> BOOST_INCLUDEDIR="/Users/cmbarton/grass_source/LAS/boostlib/include"
>>
>> cmake -G "Unix Makefiles" \
>> -D CMAKE_INSTALL_PREFIX="/Users/cmbarton/grass_source/LAS/liblasdist" \
>> -D CMAKE_OSX_ARCHITECTURES="x86_64"  \
>> -D CMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.7.sdk" \
>> -D GDAL_CONFIG="/Library/Frameworks/GDAL.framework/Programs/gdal-config" \
>> -D GDAL_INCLUDE_DIR="/Library/Frameworks/GDAL.framework/Headers" \
>> -D
>> GDAL_LIBRARY="/Library/Frameworks/GDAL.framework/unix/lib/libgdal.dylib" \
>> -D
>> GEOTIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/unix/include"
>>  \
>> -D
>> GEOTIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib"
>>  \
>> -D TIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/Headers" \
>> -D
>> TIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libtiff.dylib"
>> \
>> -D CMAKE_VERBOSE_MAKEFILE=true ../
>>
>>
>> Here is the GRASS configure error:
>>
>> 1 warning generated.
>> configure:6164: checking whether to use libLAS
>> configure:6181: checking for liblas-config
>> configure:6238: gcc -o conftest -g -O2   -arch i386 -arch x86_64
>> -isysroot /Developer/SDKs/MacOSX10.7.sdk-I/usr/local/include
>> -I/usr/local/include -I/Library/Frameworks/GDAL.framework/Headers
>> -I/Library/Frameworks/UnixImageIO.framework/unix/include
>> -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):
>>

[GRASS-dev] WARNING TO MAC USERS - WAIT UPDATING TO EL CAPITAN (OS X 10.11)

2015-10-08 Thread Michael Barton

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















___
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

2015-10-08 Thread Anna Petrášová

On Thu, Oct 8, 2015 at 8:02 PM, Michael Barton 
wrote:

> Nope.
>
> It starts to launch and gets to the start up screen, but has this error:
>
> Starting GRASS GIS...
> Unable to import pyGRASS:
> dlopen(/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib,
> 10): no suitable image found.  Did find:
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
> mach-o, but wrong architecture
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
> mach-o, but wrong architecture
> Some functionality will be not accessible
>
>
> When I select a location/mapset and start GRASS, it bombs with the same
> error I reported the other day for the student with El Capitan:
>
> GRASS 7.0.1 (Spain_fieldwork_medlands_ERTS89_Z30):~ > Unable to import
> pyGRASS: 
> dlopen(/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib,
> 10): no suitable image found.  Did find:
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
> mach-o, but wrong architecture
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
> mach-o, but wrong architecture
> Some functionality will be not accessible
> Traceback (most recent call last):
>   File
> "/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/wxgui.py",
> line 37, in 
> from lmgr.frame import GMFrame
>   File
> "/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/frame.py",
> line 50, in 
> from lmgr.layertreeimport LayerTree, LMIcons
>   File
> "/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py",
> line 37, in 
> from mapdisp.frameimport MapFrame
>   File
> "/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py",
> line 34, in 
> from vdigit.toolbarsimport VDigitToolbar
>   File
> "/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py",
> line 30, in 
> from iclass.digit   import IClassVDigit
>   File
> "/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/iclass/digit.py",
> line 23, in 
> from vdigit.wxdisplay import DisplayDriver, TYPE_AREA
> ImportError: cannot import name TYPE_AREA
>


I wonder if it's because of ctypes and the 32 vs 64 bit. Just to let you
know, I fixed this 6 weeks ago in the sense that I moved the import of the
digitizer stuff (which imports ctypes stuff) only when digitizer is
required, so theoretically the gui should open, but digitzer and nviz
wouldn't work anyway.

It seems that you need to compile laslib with both architectures, which you
said was a problem, could you perhaps describe it? I suggest to wait for
now if someone here has any idea.


> I'm at a loss here.
>
> 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 4:58 PM, Michael Barton  wrote:
>
> I got errors in...
>
>
> Errors in:
>
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/scripts/v.what.strds
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.create
>
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.support
>
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.topology
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.list
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.info
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.merge
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.remove
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.sample
>
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.register
>
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.unregister
>
> /Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.accumulate
>
>

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Michael Barton

The first thing is to compile boost with 2 architectures. That might solve the 
whole thing

Michael Barton
School of Human Evolution  Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Oct 8, 2015, at 5:14 PM, Anna Petrášová 
> wrote:

On Thu, Oct 8, 2015 at 8:02 PM, Michael Barton 
> wrote:
Nope.

It starts to launch and gets to the start up screen, but has this error:

Starting GRASS GIS...
Unable to import pyGRASS: 
dlopen(/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib,
 10): no suitable image found.  Did find:
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
Some functionality will be not accessible

When I select a location/mapset and start GRASS, it bombs with the same error I 
reported the other day for the student with El Capitan:

GRASS 7.0.1 (Spain_fieldwork_medlands_ERTS89_Z30):~ > Unable to import pyGRASS: 
dlopen(/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib,
 10): no suitable image found.  Did find:
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
Some functionality will be not accessible
Traceback (most recent call last):
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/wxgui.py",
 line 37, in 
from lmgr.frame import GMFrame
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/frame.py",
 line 50, in 
from lmgr.layertreeimport LayerTree, LMIcons
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py",
 line 37, in 
from mapdisp.frameimport MapFrame
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py",
 line 34, in 
from vdigit.toolbarsimport VDigitToolbar
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py",
 line 30, in 
from iclass.digit   import IClassVDigit
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/iclass/digit.py",
 line 23, in 
from vdigit.wxdisplay import DisplayDriver, TYPE_AREA
ImportError: cannot import name TYPE_AREA

I wonder if it's because of ctypes and the 32 vs 64 bit. Just to let you know, 
I fixed this 6 weeks ago in the sense that I moved the import of the digitizer 
stuff (which imports ctypes stuff) only when digitizer is required, so 
theoretically the gui should open, but digitzer and nviz wouldn't work anyway.

It seems that you need to compile laslib with both architectures, which you 
said was a problem, could you perhaps describe it? I suggest to wait for now if 
someone here has any idea.

I'm at a loss here.

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 4:58 PM, Michael Barton 
> wrote:

I got errors in...

Errors in:
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/scripts/v.what.strds
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.create
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.support
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.topology
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.list
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.info
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.merge
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.remove
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.sample

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Michael Barton

Nope.

It starts to launch and gets to the start up screen, but has this error:

Starting GRASS GIS...
Unable to import pyGRASS: 
dlopen(/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib,
 10): no suitable image found.  Did find:
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
Some functionality will be not accessible


When I select a location/mapset and start GRASS, it bombs with the same error I 
reported the other day for the student with El Capitan:

GRASS 7.0.1 (Spain_fieldwork_medlands_ERTS89_Z30):~ > Unable to import pyGRASS: 
dlopen(/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib,
 10): no suitable image found.  Did find:
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
Some functionality will be not accessible
Traceback (most recent call last):
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/wxgui.py",
 line 37, in 
from lmgr.frame import GMFrame
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/frame.py",
 line 50, in 
from lmgr.layertreeimport LayerTree, LMIcons
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py",
 line 37, in 
from mapdisp.frameimport MapFrame
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py",
 line 34, in 
from vdigit.toolbarsimport VDigitToolbar
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py",
 line 30, in 
from iclass.digit   import IClassVDigit
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/iclass/digit.py",
 line 23, in 
from vdigit.wxdisplay import DisplayDriver, TYPE_AREA
ImportError: cannot import name TYPE_AREA

I'm at a loss here.

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 4:58 PM, Michael Barton 
> wrote:

I got errors in...


Errors in:
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/scripts/v.what.strds
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.create
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.support
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.topology
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.list
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.info
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.merge
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.remove
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.sample
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.register
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.unregister
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.accumulate
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.accdetect
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.aggregate
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.aggregate.ds
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.colors
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.to.rast3
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.univar
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.list
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.mapcalc
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.neighbors

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Michael Barton

If I configure only for x86_64, it configures. I'm building now to see if it 
actually makes and runs. I'm concerned most about wxPython 2.8.12, which is 
still 32 bit. We'll see if the workaround that William came up with still works.

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 4:39 PM, Anna Petrášová 
> wrote:

On Thu, Oct 8, 2015 at 7:33 PM, Michael Barton 
> wrote:
I could try that. I originally build liblas with dual architecture. But current 
OS X and boost choke on dual architecture. So I built it 64 bit. I assumed that 
that means I needed to build laslib also only 64 bit. If you think I can get 
away with dual architecture there, I can give it a try.

I don't know if it helps, I just assumed this could be the problem since it 
complaint about  " file was built for archive which is not the architecture 
being linked (i386)". In the GRASS configure, you specify i386 and x86_64, but 
it can't find the i386 liblas. You can try changing GRASS configure to use only 
x86_64. But I have very vague understanding of how these things work, so I hope 
someone else could help.

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 4:07 PM, Anna Petrášová 
> wrote:

On Thu, Oct 8, 2015 at 6:26 PM, Michael Barton 
> wrote:
I built boost with both bjam and b2 for i86_64. Here are the setups I used:

cd /Users/Shared/grass_dev/boost_1_59_0
edit 
/Users/cmbarton/grass_source/LAS/boost_1_59_0/tools/build/src/tools/darwin.jam 
to delete -gdwarf-2 ]

export CXXFLAGS=-stdlib=libstdc++
./bootstrap.sh --prefix=/Users/cmbarton/grass_source/LAS/boostlib 
--without-libraries=python

## attempt 1
./bjam variant=release link=static --without-mpi -j4 macosx-version=10.7 
macosx-version-min=10.7 architecture=x86 address-model=64 install

## attempt 2
./b2 variant=release link=static --without-mpi -j4 macosx-version=10.7 
macosx-version-min=10.7 cxxflags="-arch x86_64"

I built liblas for i86_64. I initially set the prefix to put all the liblas 
files into a local directory where I could get them for packaging. Then I did 
it again letting them go into /usr/local. In all cases I get this same error. 
This is with installing it into a nice local folder.

xport BOOST_ROOT="/Users/cmbarton/grass_source/LAS/boostlib"
export BOOST_INCLUDEDIR="/Users/cmbarton/grass_source/LAS/boostlib/include"

cmake -G "Unix Makefiles" \
-D CMAKE_INSTALL_PREFIX="/Users/cmbarton/grass_source/LAS/liblasdist" \
-D CMAKE_OSX_ARCHITECTURES="x86_64"  \
-D CMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.7.sdk" \
-D GDAL_CONFIG="/Library/Frameworks/GDAL.framework/Programs/gdal-config" \
-D GDAL_INCLUDE_DIR="/Library/Frameworks/GDAL.framework/Headers" \
-D GDAL_LIBRARY="/Library/Frameworks/GDAL.framework/unix/lib/libgdal.dylib" \
-D GEOTIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/unix/include" 
 \
-D 
GEOTIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib"
  \
-D TIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/Headers" \
-D 
TIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libtiff.dylib" 
\
-D CMAKE_VERBOSE_MAKEFILE=true ../

Here is the GRASS configure error:

1 warning generated.
configure:6164: checking whether to use libLAS
configure:6181: checking for liblas-config
configure:6238: gcc -o conftest -g -O2   -arch i386 -arch x86_64 -isysroot 
/Developer/SDKs/MacOSX10.7.sdk-I/usr/local/include -I/usr/local/include 
-I/Library/Frameworks/GDAL.framework/Headers 
-I/Library/Frameworks/UnixImageIO.framework/unix/include 
-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

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Michael Barton

I got errors in...


Errors in:
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/scripts/v.what.strds
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.create
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.support
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.topology
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.list
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.info
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.merge
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.remove
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.sample
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.register
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.unregister
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.accumulate
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.accdetect
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.aggregate
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.aggregate.ds
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.colors
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.to.rast3
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.univar
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.list
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.mapcalc
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.neighbors
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.series
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.export
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.out.vtk
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.import
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.gapfill
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast.extract
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast3d.list
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast3d.extract
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast3d.mapcalc
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rast3d.univar
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.rename
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.select
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.snap
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.shift
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.vect.list
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.vect.db.select
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.vect.export
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.vect.extract
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.vect.import
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.vect.what.strds
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.vect.observe.strds
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/temporal/t.vect.univar
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/visualization/wximgview
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Thu Oct  8 16:51:28 MST 2015
make: *** [default] Error 1


Switching to the relevant folder and making again fixed the tgis and 
v.what.strds problems, meaning that this is a makefile problem in GRASS 7.0.1

But wximgview would not compile with what appears to be a 32/64 bit conflict

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** 
[/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/dist.x86_64-apple-darwin14.5.0/bin/wximgview]
 Error 1

I will make a test binary anyway. If it launches, I'll send you a link to try. 
Not sure what to do about wximgview.

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 4:52 PM,

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Michael Barton

Nope.

ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/Release/liblas.2.3.0.dylib] Error 1
make[1]: *** [src/CMakeFiles/las.dir/all] Error 2
make: *** [all] Error 2




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 4:33 PM, Michael Barton 
> wrote:

I could try that. I originally build liblas with dual architecture. But current 
OS X and boost choke on dual architecture. So I built it 64 bit. I assumed that 
that means I needed to build laslib also only 64 bit. If you think I can get 
away with dual architecture there, I can give it a try.

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 4:07 PM, Anna Petrášová 
> wrote:



On Thu, Oct 8, 2015 at 6:26 PM, Michael Barton 
> wrote:
I built boost with both bjam and b2 for i86_64. Here are the setups I used:

cd /Users/Shared/grass_dev/boost_1_59_0
edit 
/Users/cmbarton/grass_source/LAS/boost_1_59_0/tools/build/src/tools/darwin.jam 
to delete -gdwarf-2 ]

export CXXFLAGS=-stdlib=libstdc++
./bootstrap.sh --prefix=/Users/cmbarton/grass_source/LAS/boostlib 
--without-libraries=python

## attempt 1
./bjam variant=release link=static --without-mpi -j4 macosx-version=10.7 
macosx-version-min=10.7 architecture=x86 address-model=64 install

## attempt 2
./b2 variant=release link=static --without-mpi -j4 macosx-version=10.7 
macosx-version-min=10.7 cxxflags="-arch x86_64"

I built liblas for i86_64. I initially set the prefix to put all the liblas 
files into a local directory where I could get them for packaging. Then I did 
it again letting them go into /usr/local. In all cases I get this same error. 
This is with installing it into a nice local folder.

xport BOOST_ROOT="/Users/cmbarton/grass_source/LAS/boostlib"
export BOOST_INCLUDEDIR="/Users/cmbarton/grass_source/LAS/boostlib/include"

cmake -G "Unix Makefiles" \
-D CMAKE_INSTALL_PREFIX="/Users/cmbarton/grass_source/LAS/liblasdist" \
-D CMAKE_OSX_ARCHITECTURES="x86_64"  \
-D CMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.7.sdk" \
-D GDAL_CONFIG="/Library/Frameworks/GDAL.framework/Programs/gdal-config" \
-D GDAL_INCLUDE_DIR="/Library/Frameworks/GDAL.framework/Headers" \
-D GDAL_LIBRARY="/Library/Frameworks/GDAL.framework/unix/lib/libgdal.dylib" \
-D GEOTIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/unix/include" 
 \
-D 
GEOTIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libgeotiff.dylib"
  \
-D TIFF_INCLUDE_DIR="/Library/Frameworks/UnixImageIO.framework/Headers" \
-D 
TIFF_LIBRARY="/Library/Frameworks/UnixImageIO.framework/unix/lib/libtiff.dylib" 
\
-D CMAKE_VERBOSE_MAKEFILE=true ../


Here is the GRASS configure error:

1 warning generated.
configure:6164: checking whether to use libLAS
configure:6181: checking for liblas-config
configure:6238: gcc -o conftest -g -O2   -arch i386 -arch x86_64 -isysroot 
/Developer/SDKs/MacOSX10.7.sdk-I/usr/local/include -I/usr/local/include 
-I/Library/Frameworks/GDAL.framework/Headers 
-I/Library/Frameworks/UnixImageIO.framework/unix/include 
-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

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-08 Thread Glynn Clements


Michael Barton wrote:

> But wximgview would not compile with what appears to be a 32/64 bit conflict

wximgview is (AFAIK) the only program which links against the
wxWidgets libraries.

But it has been obsoleted by wxpyimgview (a wxPython version), so I
see no reason not to simply remove it (and the wxWidgets configure
checks as well).

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wx.metadata ready for testing

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

[GRASS-dev] r.stream.watersheds & r.stream.variables add-on

[GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

[GRASS-dev] WARNING TO MAC USERS - WAIT UPDATING TO EL CAPITAN (OS X 10.11)

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] GRASS will not not find laslib

17 matches

Site Navigation

Mail list logo

Footer information