[GRASS-dev] libLAS in GRASS 7.4 for Mac

Fri Feb 9 07:14:03 PST 2018

Moving libLAS+Mac+Anaconda discussion to the list.

On Fri, Feb 9, 2018 at 12:23 AM, Michael Barton <Michael.Barton at asu.edu>
wrote:

>
> The Anaconda LAS package seems to have all the binary distribution files
> and libraries built by compiling LAS from source (i.e., those that I
> bundled previously)--EXCEPT for liblas-config.
>

That's what I'm saying. Open an issue (wherever appropriate) to fix libLAS
Anaconda package. Perhaps all you need is a development version of this
package if Anaconda packaging is similar to Linux packaging.

> It would be nice if I could build GRASS with LAS support without the need
> for this file.
>

That seems like a workaround for an upstream issue as opposed to reporting
the issue upstream as first step in fixing it. If libLAS is dropping
liblas-config a way to get the libraries and headers or of if liblas-config
usage in this context is not appropriate (which I can't tell), then yes, we
should switch to specifying the libraries manually.

>
> I've looked at liblas-config and can see what it does. But AFAICT, when
> running v.in.lidar or r.in.lidar, they are only really using the LAS
> libraries and binary tools las2txt and laszip.
>

liblas-config is needed for the compilation of things against libLAS, not
for runtime. It's the same as with the C header files, you don't need them
during runtime, but you need them for compilation.

> So perhaps GRASS is not using any of the non-LAS linked libraries that
> laslib-config provides paths to (e.g., boost and gdal).
>

As far as I understand, they are needed for the compilation because libLAS
needs them.

> If GRASS actually needs all of the linked files that laslib-config
> provides, then we can't just use the binaries in the Anaconda LAS tools
> package.
>

libLAS uses Boost and (I think optionally) GDAL, so I would expect that to
be part of the Anaconda package (or installed as a dependency).

> The only recourse is to try to recompile it in an Anaconda environment and
> have it create an appropriate laslib-config. A serious pain.
>

I would not do that until you see what the upstream (Anaconda package)
people say.

In the mean time, before the issue is resolved upstream, you can create the
liblas-config, youself. It will look something like this:

if [ "$1" = "--libs" ]
then
    echo -L/usr/lib -llas -llas_c -L... /usr/lib/x86_64-linux-gnu/libtiff.so
...

I'm attaching a full script, but you need to supply the values appropriate
for Mac/your computer. Start with what you would put to the
--with-liblas-libs=...

Unrelated to the Mac issue, I wonder if it is a probable that we are not
making use of the --defines option in liblas-config (which gives
"-DHAVE_GDAL=1 -DHAVE_LIBGEOTIFF=1", but perhaps it is important only when
compiling libLAS binary tools.

>
> But if all GRASS really needs are the LAS binaries and libraries
> (liblas.dylib on the Mac), then maybe we can just point to the resources it
> needs.
>

Try the attached script to do that. For me GRASS configures successfully
when I use it instead of liblas-config:

--with-liblas="/home/.../fake-liblas-config.sh"

Best,
Vaclav

>
> Cheers
> 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 <(480)%20965-6262> (SHESC), 480-965-8130
> <(480)%20965-8130>/727-9746 (CSDC)
> fax: 480-965-7671 <(480)%20965-7671> (SHESC),  480-727-0709
> <(480)%20727-0709> (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
> On Feb 8, 2018, at 6:16 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
>
> Hi Michael,
>
> I would say first thing is to check if it is really missing and if so why
> is that. I assume you have *-config for GDAL, so in general there is no
> special thing why there should be no *-configure on Mac.
>
> Then you can supply your own liblas-config. What you need is a bash script
> which will behave like this:
>
> $ liblas-config --libs
> -L/usr/lib -llas -llas_c -L/usr/lib/x86_64-linux-gnu
> /usr/lib/x86_64-linux-gnu/libboost_program_options.so
> /usr/lib/x86_64-linux-gnu/libboost_thread.so /usr/lib/libgdal.so
> /usr/lib/x86_64-linux-gnu/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so
> $ liblas-config --cflags
> -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security
> -Wdate-time -D_FORTIFY_SOURCE=2
> $ liblas-config --includes
> -I/usr/include -I/usr/include/gdal -I/usr/include/geotiff
> -I/usr/include/x86_64-linux-gnu
>
> The last resort would be to add --with-*-libs at el. to configure.in in
> GRASS but there are 2 reasons why not to do that: 1) I don't see the
> combination of *-config and --with-*-libs at el. to be used now. 2) The fix
> really should be done on the libLAS site.
>
> If we would switch from liblas-config just to --with-*-libs at el., it
> would be much harder for the average person compiling GRASS. I don't
> understand it 100% but I think you need to a list of libLAS dependencies to
> make it work (such as /usr/lib/x86_64-linux-gnu/libboost_thread.so) which
> might be hard to get. On the other hand, liblas-config takes care of
> providing path to the right libraries.
>
> I just compiled libLAS from latest source on Linux and liblas-config was
> in dir called `app` after build (i.e. `make`) and after `make install` it
> is in the install dir under `bin` with other executables. So as far as I
> can tell, libLAS should have liblas-config.
>
> Vaclav
>
> On Thu, Feb 8, 2018 at 3:49 PM, Markus Neteler <neteler at osgeo.org> wrote:
> >
> > ...
> >
> > On Thu, Feb 8, 2018 at 9:05 PM, Michael Barton <Michael.Barton at asu.edu>
> wrote:
> > > ...
> > > However, the Anaconda version of LAS tools does not include a
> liblas-config
> > > file. The presence of this file is used by GRASS as a proxy check for
> the
> > > existence of LAS libraries. I'm not sure if compiling v.in.lidar and
> > > r.in.lidar actually do anything with the config file beyond finding
> > > liblas.dylib. But if I try to point configure to the libraries directly
> > > (with-liblas-libraries="...") it is ignored.
> > >
> > > So do you have any thoughts about how to get GRASS to use the liblas
> > > resources if liblas-config is missing?
> > >
> > > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180209/94db751b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fake-liblas-config.sh
Type: application/x-sh
Size: 833 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180209/94db751b/attachment-0001.sh>