[GRASS-dev] r.in.lidar not running in Mac binaries for 7.1

[Vaclav Petras]

[Was: Re: [GRASS-dev] New Mac binaries uploaded]

Hi Michael,

On Mon, Aug 24, 2015 at 11:45 PM, Michael Barton <Michael.Barton at 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?
>

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 <woklist at 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.barton at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150915/421c684e/attachment.html>