Thanks Vaclav. ____________________ 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 Feb 9, 2018, at 8:14 AM, Vaclav Petras <wenzesl...@gmail.com<mailto:wenzesl...@gmail.com>> wrote: Moving libLAS+Mac+Anaconda discussion to the list. On Fri, Feb 9, 2018 at 12:23 AM, Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@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<tel:(480)%20965-6262> (SHESC), 480-965-8130<tel:(480)%20965-8130>/727-9746 (CSDC) fax: 480-965-7671<tel:(480)%20965-7671> (SHESC), 480-727-0709<tel:(480)%20727-0709> (CSDC) www: http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=koceBYgeMqhIORXyOL-wIEeo3WDdsWFZKza5z7-oZT8&s=2s299vwE06IODZNlQBKe9qMmWwVPg2Ka4A-aCuv_pEs&e=>, http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=koceBYgeMqhIORXyOL-wIEeo3WDdsWFZKza5z7-oZT8&s=otYeQ8UOhP9rfAUxhw95siPL86C1goWF2m1DzmOcGvo&e=> On Feb 8, 2018, at 6:16 PM, Vaclav Petras <wenzesl...@gmail.com<mailto:wenzesl...@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<https://urldefense.proofpoint.com/v2/url?u=http-3A__configure.in&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=koceBYgeMqhIORXyOL-wIEeo3WDdsWFZKza5z7-oZT8&s=mSkvZCKAiuPaLTfgUcV6R5p1tLg1UoZkuzXgyXUQ1L0&e=> 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 <nete...@osgeo.org<mailto:nete...@osgeo.org>> wrote: > > ... > > On Thu, Feb 8, 2018 at 9:05 PM, Michael Barton > <michael.bar...@asu.edu<mailto:michael.bar...@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 <fake-liblas-config.sh>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
