So far I'm stuck on compiling liblas with new gdal and no one has had any advice for a way forward. If that can happen, I can recompile with new liblas. That is why I was hoping for laslib. It may be that I just did not link it correctly. I'm open to advice.
Michael Barton School of Human Evolution &Social Change Center for Social Dynamics & Complexity Arizona State University ...Sent from my iPad On Sep 15, 2015, at 6:02 PM, Vaclav Petras <[email protected]<mailto:[email protected]>> wrote: [Was: Re: [GRASS-dev] New Mac binaries uploaded] Hi Michael, On Mon, Aug 24, 2015 at 11:45 PM, Michael Barton <[email protected]<mailto:[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]<mailto:[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]<mailto:[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
