[Was: Re: [GRASS-dev] New Mac binaries uploaded] Hi Michael,
On Mon, Aug 24, 2015 at 11:45 PM, Michael Barton <[email protected]> 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? > the binary in Dropbox has lasinfo et al. from LAStools. However, r.in.lidar doesn't work (2 different computers). Does it work for you? Running r.in.lidar or v.in.lidar --help and says dyld: Library not loaded: /usr/local/lib/liblas.2.2.0.dylib As I said earlier, GRASS is made to dynamically link with libLAS. In case the API of LAStools library is the same, there might be a way to change the GRASS configuration and makefiles or the ones for LAStools, so that GRASS can compile with LAStools statically but I don't know the way. Currently with LAStools compiled with GRASS on Mac, you can use the tools in command line but it's useless for GRASS modules, namely r|v.in.lidar. Thanks, Vaclav PS: Although I'm working on migration to PDAL [1], it will take some time before it gets even to 7.1 (trunk), not mentioning 7.0. So, the libLAS library is still needed. [1] https://trac.osgeo.org/grass/ticket/2732 > On Aug 24, 2015, at 8:40 PM, William Kyngesburye <[email protected]> > 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 <[email protected]> > 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 > >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
