[GRASS-dev] libLAS on Ubuntu 14.04

wenzeslaus · May 22, 2014, 7:25pm

Hi,

I was trying to compile GRASS with libLAS but ./configure says no.

I used:

–with-liblas-config=/usr/bin/liblas-config

and I have all liblas packages from standard Ubuntu 14.04 repository (libLAS version is 1.7.0 which is the current stable release).

Since configure went OK but the result for libLAS was “no”, I tried to compile and run the ./configure’s testing code myself.

Code:

#include <liblas/capi/liblas.h>
int main() {
LASReader_Create(“foo”);
; return 0; }

Compilation:

gcc liblastest.c -o liblastest -ggdb -L/usr/lib -llas -llas_c -L/usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0 /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 /usr/lib/libgdal.so /usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so $(liblas-config --includes)

Debugging test:

gdb liblastest

Starting program: /home/vasek/dev/grass/test/liblastest

[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/x86_64-linux-gnu/libthread_db.so.1”.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7285471 in std::istream::seekg(std::fpos<__mbstate_t>) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x00007ffff7285471 in std::istream::seekg(std::fpos<__mbstate_t>) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00007ffff759597b in liblas::detail::reader::Header::ReadHeader() () from /usr/lib/liblas.so.2
#2 0x00007ffff754713b in liblas::ReaderFactory::CreateWithStream(std::istream&) () from /usr/lib/liblas.so.2
#3 0x00007ffff7bb1a80 in LASReader_Create () from /usr/lib/liblas_c.so.2
#4 0x00000000004006ab in main () at liblastest.c:4

So the test failed with segmentation fault but it would actually fail during compilation if I would use liblas-config --libs because the boost libraries are libboost_program_options.so.1.54.0 on my computer while liblas-config --libs says just libboost_program_options.so (same for thread library).

It seems that the thing with boost libraries is a packaging issue but I’m not sure about the other ones. I can repeat it outside GRASS I don’t know if this is actually what GRASS is doing and if it makes sense.

Was somebody successful with libLAS on Ubuntu 14.04 and what is the general procedure for Linux anyway?

Thanks,

Vaclav

Yann4 · May 23, 2014, 12:47am

I can confirm the issue,

also by trying these configure options it is not helping:
--with-liblas --with-liblas-config
--with-liblas --with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes --with-liblas-config
--with-liblas=yes --with-liblas-config=/usr/bin/liblas-config

Also two targets are found, both valid (v1.7.0) and identical:
whereis liblas-config
liblas-config: /usr/bin/liblas-config /usr/bin/X11/liblas-config
/usr/share/man/man1/liblas-config.1.gz

$ ls -aslh /usr/bin/X11/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/X11/liblas-config
$ ls -aslh /usr/bin/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/liblas-config

On 23/05/2014, Vaclav Petras <wenzeslaus@gmail.com> wrote:

Hi,

I was trying to compile GRASS with libLAS but ./configure says no.

I used:

--with-liblas-config=/usr/bin/liblas-config

and I have all liblas packages from standard Ubuntu 14.04 repository
(libLAS version is 1.7.0 which is the current stable release).

Since configure went OK but the result for libLAS was "no", I tried to
compile and run the ./configure's testing code myself.

Code:

#include <liblas/capi/liblas.h>
int main() {
LASReader_Create("foo");
; return 0; }

Compilation:

gcc liblastest.c -o liblastest -ggdb -L/usr/lib -llas -llas_c
-L/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 /usr/lib/libgdal.so
/usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so $(liblas-config
--includes)

Debugging test:

gdb liblastest

Starting program: /home/vasek/dev/grass/test/liblastest

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7285471 in std::istream::seekg(std::fpos<__mbstate_t>) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x00007ffff7285471 in std::istream::seekg(std::fpos<__mbstate_t>) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00007ffff759597b in liblas::detail::reader::Header::ReadHeader() ()
from /usr/lib/liblas.so.2
#2 0x00007ffff754713b in
liblas::ReaderFactory::CreateWithStream(std::istream&) () from
/usr/lib/liblas.so.2
#3 0x00007ffff7bb1a80 in LASReader_Create () from /usr/lib/liblas_c.so.2
#4 0x00000000004006ab in main () at liblastest.c:4

So the test failed with segmentation fault but it would actually fail
during compilation if I would use `liblas-config --libs` because the boost
libraries are `libboost_program_options.so.1.54.0` on my computer while
`liblas-config --libs` says just `libboost_program_options.so` (same for
thread library).

It seems that the thing with boost libraries is a packaging issue but I'm
not sure about the other ones. I can repeat it outside GRASS I don't know
if this is actually what GRASS is doing and if it makes sense.

Was somebody successful with libLAS on Ubuntu 14.04 and what is the general
procedure for Linux anyway?

Thanks,
Vaclav

--
----

Glynn_Clements1 · May 23, 2014, 6:53pm

Vaclav Petras wrote:

So the test failed with segmentation fault

Possibly due to linking with gcc rather than g++. But that doesn't
matter, as configure tests don't normally try to execute the program
(that doesn't work if you're cross-compiling); they only care whether
linking succeeds.

but it would actually fail
during compilation if I would use `liblas-config --libs` because the boost
libraries are `libboost_program_options.so.1.54.0` on my computer while
`liblas-config --libs` says just `libboost_program_options.so` (same for
thread library).

You may need to install a -devel package, e.g. boost-devel or
whatever.

Typically, the unversioned symlink is in the -devel package, as it's
only needed for compiling programs which use the library; running them
will use either the library itself or a symlink which includes at
least the major version number.

--
Glynn Clements <glynn@gclements.plus.com>

wenzeslaus · May 23, 2014, 7:25pm

On Fri, May 23, 2014 at 2:53 PM, Glynn Clements <glynn@gclements.plus.com>wrote:

Vaclav Petras wrote:

> So the test failed with segmentation fault

Possibly due to linking with gcc rather than g++. But that doesn't
matter, as configure tests don't normally try to execute the program
(that doesn't work if you're cross-compiling); they only care whether
linking succeeds.

I have to remember this gcc vs g++ possible issue and that ./cofigure does
not execute. However, it did not helped me now. My sample program still
segfaults when compiled with g++.

> but it would actually fail
> during compilation if I would use `liblas-config --libs` because the
boost
> libraries are `libboost_program_options.so.1.54.0` on my computer while
> `liblas-config --libs` says just `libboost_program_options.so` (same for
> thread library).

You may need to install a -devel package, e.g. boost-devel or
whatever.

Typically, the unversioned symlink is in the -devel package, as it's
only needed for compiling programs which use the library; running them
will use either the library itself or a symlink which includes at
least the major version number.

I installed libboost-thread-dev and libboost-program-options-dev and
compilation works with $(liblas-config --libs) $(liblas-config --includes).
So, it should work in ./configure but the result is still "libLAS support:
no".

--
Glynn Clements <glynn@gclements.plus.com>

Mohammed_Rashad · May 23, 2014, 7:35pm

Hi Vaclav,

If it helps: http://trac.osgeo.org/grass/ticket/2065

···

On Fri, May 23, 2014 at 9:25 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–

Regards,
Rashad

On Fri, May 23, 2014 at 2:53 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

Vaclav Petras wrote:

So the test failed with segmentation fault

Possibly due to linking with gcc rather than g++. But that doesn’t
matter, as configure tests don’t normally try to execute the program
(that doesn’t work if you’re cross-compiling); they only care whether
linking succeeds.

I have to remember this gcc vs g++ possible issue and that ./cofigure does not execute. However, it did not helped me now. My sample program still segfaults when compiled with g++.

but it would actually fail
during compilation if I would use liblas-config --libs because the boost
libraries are libboost_program_options.so.1.54.0 on my computer while
liblas-config --libs says just libboost_program_options.so (same for
thread library).

You may need to install a -devel package, e.g. boost-devel or
whatever.

Typically, the unversioned symlink is in the -devel package, as it’s
only needed for compiling programs which use the library; running them
will use either the library itself or a symlink which includes at
least the major version number.

I installed libboost-thread-dev and libboost-program-options-dev and compilation works with $(liblas-config --libs) $(liblas-config --includes). So, it should work in ./configure but the result is still “libLAS support: no”.

–
Glynn Clements <glynn@gclements.plus.com>

wenzeslaus · May 23, 2014, 8:04pm

On Fri, May 23, 2014 at 3:35 PM, Rashad M <mohammedrashadkm@gmail.com>wrote:

Hi Vaclav,

If it helps: http://trac.osgeo.org/grass/ticket/2065

Thanks, I tried to unify the variables (r57541 and the patch from #2065):

CFLAGS="$CFLAGS $LIBLAS_CFLAGS $LIBLAS_INC"
CPPFLAGS="$CPPFLAGS $LIBLAS_CPPFLAGS $LIBLAS_INC"

but it did not help. I see that the ticket is closed and it puzzles me that
it is not enough for me.

On Fri, May 23, 2014 at 9:25 PM, Vaclav Petras <wenzeslaus@gmail.com>wrote:

On Fri, May 23, 2014 at 2:53 PM, Glynn Clements <glynn@gclements.plus.com
> wrote:

Vaclav Petras wrote:

> So the test failed with segmentation fault

Possibly due to linking with gcc rather than g++. But that doesn't
matter, as configure tests don't normally try to execute the program
(that doesn't work if you're cross-compiling); they only care whether
linking succeeds.

I have to remember this gcc vs g++ possible issue and that ./cofigure
does not execute. However, it did not helped me now. My sample program
still segfaults when compiled with g++.

I've tried also cxxflags and a file with cpp extension:

g++ liblastest.cpp -o liblastest -ggdb $(liblas-config --libs)
$(liblas-config --includes) $(liblas-config --cxxflags)

but it still segfaults (with and without -ggdb). Should I report this
somewhere (Launchpad, libLAS)?

> but it would actually fail

> during compilation if I would use `liblas-config --libs` because the
boost
> libraries are `libboost_program_options.so.1.54.0` on my computer while
> `liblas-config --libs` says just `libboost_program_options.so` (same
for
> thread library).

You may need to install a -devel package, e.g. boost-devel or
whatever.

Typically, the unversioned symlink is in the -devel package, as it's
only needed for compiling programs which use the library; running them
will use either the library itself or a symlink which includes at
least the major version number.

I installed libboost-thread-dev and libboost-program-options-dev and
compilation works with $(liblas-config --libs) $(liblas-config --includes).
So, it should work in ./configure but the result is still "libLAS support:
no".

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Regards,
Rashad

Mohammed_Rashad · May 23, 2014, 8:52pm

Hi Vaclav,

try linking to las_c instead of las

gcc liblastest.c -o liblastest -ggdb -L/usr/lib -llas_c /usr/lib/libgdal.so /usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so

boost and las.so not required here, i think

···

On Fri, May 23, 2014 at 10:04 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

–

Regards,
Rashad

On Fri, May 23, 2014 at 3:35 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hi Vaclav,

If it helps: http://trac.osgeo.org/grass/ticket/2065

Thanks, I tried to unify the variables (r57541 and the patch from #2065):

CFLAGS=“$CFLAGS $LIBLAS_CFLAGS $LIBLAS_INC”
CPPFLAGS=“$CPPFLAGS $LIBLAS_CPPFLAGS $LIBLAS_INC”

but it did not help. I see that the ticket is closed and it puzzles me that it is not enough for me.

I’ve tried also cxxflags and a file with cpp extension:

g++ liblastest.cpp -o liblastest -ggdb $(liblas-config --libs) $(liblas-config --includes) $(liblas-config --cxxflags)

but it still segfaults (with and without -ggdb). Should I report this somewhere (Launchpad, libLAS)?

On Fri, May 23, 2014 at 9:25 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, May 23, 2014 at 2:53 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

Vaclav Petras wrote:

So the test failed with segmentation fault

Possibly due to linking with gcc rather than g++. But that doesn’t
matter, as configure tests don’t normally try to execute the program
(that doesn’t work if you’re cross-compiling); they only care whether
linking succeeds.

I have to remember this gcc vs g++ possible issue and that ./cofigure does not execute. However, it did not helped me now. My sample program still segfaults when compiled with g++.

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–

Regards,
Rashad

but it would actually fail
during compilation if I would use liblas-config --libs because the boost
libraries are libboost_program_options.so.1.54.0 on my computer while
liblas-config --libs says just libboost_program_options.so (same for
thread library).

You may need to install a -devel package, e.g. boost-devel or
whatever.

Typically, the unversioned symlink is in the -devel package, as it’s
only needed for compiling programs which use the library; running them
will use either the library itself or a symlink which includes at
least the major version number.

I installed libboost-thread-dev and libboost-program-options-dev and compilation works with $(liblas-config --libs) $(liblas-config --includes). So, it should work in ./configure but the result is still “libLAS support: no”.

–
Glynn Clements <glynn@gclements.plus.com>

wenzeslaus · May 23, 2014, 8:58pm

On Fri, May 23, 2014 at 4:52 PM, Rashad M <mohammedrashadkm@gmail.com>wrote:

Hi Vaclav,

try linking to las_c instead of las

gcc liblastest.c -o liblastest -ggdb -L/usr/lib -llas_c /usr/lib/libgdal.so
/usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so

boost and las.so not required here, i think

Thanks but no success here.

On Fri, May 23, 2014 at 10:04 PM, Vaclav Petras <wenzeslaus@gmail.com>wrote:

On Fri, May 23, 2014 at 3:35 PM, Rashad M <mohammedrashadkm@gmail.com>wrote:

Hi Vaclav,

If it helps: http://trac.osgeo.org/grass/ticket/2065

Thanks, I tried to unify the variables (r57541 and the patch from #2065):

CFLAGS="$CFLAGS $LIBLAS_CFLAGS $LIBLAS_INC"
CPPFLAGS="$CPPFLAGS $LIBLAS_CPPFLAGS $LIBLAS_INC"

but it did not help. I see that the ticket is closed and it puzzles me
that it is not enough for me.

On Fri, May 23, 2014 at 9:25 PM, Vaclav Petras <wenzeslaus@gmail.com>wrote:

On Fri, May 23, 2014 at 2:53 PM, Glynn Clements <
glynn@gclements.plus.com> wrote:

Vaclav Petras wrote:

> So the test failed with segmentation fault

Possibly due to linking with gcc rather than g++. But that doesn't
matter, as configure tests don't normally try to execute the program
(that doesn't work if you're cross-compiling); they only care whether
linking succeeds.

I have to remember this gcc vs g++ possible issue and that ./cofigure
does not execute. However, it did not helped me now. My sample program
still segfaults when compiled with g++.

I've tried also cxxflags and a file with cpp extension:

g++ liblastest.cpp -o liblastest -ggdb $(liblas-config --libs)
$(liblas-config --includes) $(liblas-config --cxxflags)

but it still segfaults (with and without -ggdb). Should I report this
somewhere (Launchpad, libLAS)?

> but it would actually fail

> during compilation if I would use `liblas-config --libs` because the
boost
> libraries are `libboost_program_options.so.1.54.0` on my computer
while
> `liblas-config --libs` says just `libboost_program_options.so` (same
for
> thread library).

You may need to install a -devel package, e.g. boost-devel or
whatever.

Typically, the unversioned symlink is in the -devel package, as it's
only needed for compiling programs which use the library; running them
will use either the library itself or a symlink which includes at
least the major version number.

I installed libboost-thread-dev and libboost-program-options-dev and
compilation works with $(liblas-config --libs) $(liblas-config --includes).
So, it should work in ./configure but the result is still "libLAS support:
no".

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Regards,
Rashad

--
Regards,
Rashad

Mohammed_Rashad · May 23, 2014, 9:03pm

Much interesting why it ask for c++ when using C headers ?

···

On Fri, May 23, 2014 at 10:58 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

–

Regards,
Rashad

On Fri, May 23, 2014 at 4:52 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hi Vaclav,

try linking to las_c instead of las

gcc liblastest.c -o liblastest -ggdb -L/usr/lib -llas_c /usr/lib/libgdal.so /usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so

boost and las.so not required here, i think

Thanks but no success here.

On Fri, May 23, 2014 at 10:04 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

–

Regards,
Rashad

On Fri, May 23, 2014 at 3:35 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hi Vaclav,

If it helps: http://trac.osgeo.org/grass/ticket/2065

Thanks, I tried to unify the variables (r57541 and the patch from #2065):

CFLAGS=“$CFLAGS $LIBLAS_CFLAGS $LIBLAS_INC”
CPPFLAGS=“$CPPFLAGS $LIBLAS_CPPFLAGS $LIBLAS_INC”

but it did not help. I see that the ticket is closed and it puzzles me that it is not enough for me.

I’ve tried also cxxflags and a file with cpp extension:

g++ liblastest.cpp -o liblastest -ggdb $(liblas-config --libs) $(liblas-config --includes) $(liblas-config --cxxflags)

but it still segfaults (with and without -ggdb). Should I report this somewhere (Launchpad, libLAS)?

On Fri, May 23, 2014 at 9:25 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, May 23, 2014 at 2:53 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

Vaclav Petras wrote:

So the test failed with segmentation fault

Possibly due to linking with gcc rather than g++. But that doesn’t
matter, as configure tests don’t normally try to execute the program
(that doesn’t work if you’re cross-compiling); they only care whether
linking succeeds.

I have to remember this gcc vs g++ possible issue and that ./cofigure does not execute. However, it did not helped me now. My sample program still segfaults when compiled with g++.

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–

Regards,
Rashad

but it would actually fail
during compilation if I would use liblas-config --libs because the boost
libraries are libboost_program_options.so.1.54.0 on my computer while
liblas-config --libs says just libboost_program_options.so (same for
thread library).

You may need to install a -devel package, e.g. boost-devel or
whatever.

Typically, the unversioned symlink is in the -devel package, as it’s
only needed for compiling programs which use the library; running them
will use either the library itself or a symlink which includes at
least the major version number.

I installed libboost-thread-dev and libboost-program-options-dev and compilation works with $(liblas-config --libs) $(liblas-config --includes). So, it should work in ./configure but the result is still “libLAS support: no”.

–
Glynn Clements <glynn@gclements.plus.com>

Mohammed_Rashad · May 23, 2014, 9:13pm

Hi again!.

Do you have ctest passed?

For me i have:

Test command: /home/rashad/Desktop/libLAS-1.7.0/build/bin/Release/liblas_test “/home/rashad/Desktop/libLAS-1.7.0/test/data”
1: Test timeout computed to be: 1500
1: libLAS Test Suite:
1: ==================
1: liblas::Bounds: …
1: liblas::Error: …
1: liblas::Header: …
1: liblas::Point: …
1: liblas::Reader: …
1: liblas::SpatialReference: .
1: liblas::VariableRecord: …
1: liblas::Writer: …
1: liblas::guid: …
1: liblas::lasreader_iterator: …
1:
1: tests summary: ok:88
1/1 Test #1: liblas_test … Passed 0.02 sec

100% tests passed, 0 tests failed out of 1

If so you need update the test in grass configure. BTW. it seems like c library is not used anymore.You must check this with libLAS devs. But for now try updating configure test code

···

On Fri, May 23, 2014 at 11:03 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Much interesting why it ask for c++ when using C headers ?

–

Regards,
Rashad

On Fri, May 23, 2014 at 10:58 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

–

Regards,
Rashad

On Fri, May 23, 2014 at 4:52 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hi Vaclav,

try linking to las_c instead of las

gcc liblastest.c -o liblastest -ggdb -L/usr/lib -llas_c /usr/lib/libgdal.so /usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so

boost and las.so not required here, i think

Thanks but no success here.

On Fri, May 23, 2014 at 10:04 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

–

Regards,
Rashad

On Fri, May 23, 2014 at 3:35 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hi Vaclav,

If it helps: http://trac.osgeo.org/grass/ticket/2065

Thanks, I tried to unify the variables (r57541 and the patch from #2065):

CFLAGS=“$CFLAGS $LIBLAS_CFLAGS $LIBLAS_INC”
CPPFLAGS=“$CPPFLAGS $LIBLAS_CPPFLAGS $LIBLAS_INC”

but it did not help. I see that the ticket is closed and it puzzles me that it is not enough for me.

I’ve tried also cxxflags and a file with cpp extension:

g++ liblastest.cpp -o liblastest -ggdb $(liblas-config --libs) $(liblas-config --includes) $(liblas-config --cxxflags)

but it still segfaults (with and without -ggdb). Should I report this somewhere (Launchpad, libLAS)?

On Fri, May 23, 2014 at 9:25 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, May 23, 2014 at 2:53 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

Vaclav Petras wrote:

So the test failed with segmentation fault

Possibly due to linking with gcc rather than g++. But that doesn’t
matter, as configure tests don’t normally try to execute the program
(that doesn’t work if you’re cross-compiling); they only care whether
linking succeeds.

I have to remember this gcc vs g++ possible issue and that ./cofigure does not execute. However, it did not helped me now. My sample program still segfaults when compiled with g++.

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–

Regards,
Rashad

but it would actually fail
during compilation if I would use liblas-config --libs because the boost
libraries are libboost_program_options.so.1.54.0 on my computer while
liblas-config --libs says just libboost_program_options.so (same for
thread library).

You may need to install a -devel package, e.g. boost-devel or
whatever.

Typically, the unversioned symlink is in the -devel package, as it’s
only needed for compiling programs which use the library; running them
will use either the library itself or a symlink which includes at
least the major version number.

I installed libboost-thread-dev and libboost-program-options-dev and compilation works with $(liblas-config --libs) $(liblas-config --includes). So, it should work in ./configure but the result is still “libLAS support: no”.

–
Glynn Clements <glynn@gclements.plus.com>

Javier_Martinez-Lope · May 29, 2014, 5:09pm

Hi,

I had the same problem with the latest grass 71 svn version (from
today) under ubuntu 14.04 and I certainly solved it installing
libboost-all-dev and the config option: --with-liblas=yes
--with-liblas-config=/usr/bin/liblas-config

Thank you and cheers,

Javier

On Fri, May 23, 2014 at 11:13 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hi again!.

Do you have ctest passed?

For me i have:

Test command:
/home/rashad/Desktop/libLAS-1.7.0/build/bin/Release/liblas_test
"/home/rashad/Desktop/libLAS-1.7.0/test/data"
1: Test timeout computed to be: 1500
1: libLAS Test Suite:
1: ==================
1: liblas::Bounds: ....
1: liblas::Error: ...
1: liblas::Header: ............
1: liblas::Point: ...................
1: liblas::Reader: ........
1: liblas::SpatialReference: .
1: liblas::VariableRecord: ......
1: liblas::Writer: ......
1: liblas::guid: .......
1: liblas::lasreader_iterator: ......................
1:
1: tests summary: ok:88
1/1 Test #1: liblas_test ...................... Passed 0.02 sec

100% tests passed, 0 tests failed out of 1

If so you need update the test in grass configure. BTW. it seems like c
library is not used anymore.You must check this with libLAS devs. But for
now try updating configure test code

On Fri, May 23, 2014 at 11:03 PM, Rashad M <mohammedrashadkm@gmail.com>
wrote:

Much interesting why it ask for c++ when using C headers ?

On Fri, May 23, 2014 at 10:58 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:

On Fri, May 23, 2014 at 4:52 PM, Rashad M <mohammedrashadkm@gmail.com>
wrote:

Hi Vaclav,

try linking to las_c instead of las

gcc liblastest.c -o liblastest -ggdb -L/usr/lib -llas_c
/usr/lib/libgdal.so /usr/lib/libgeotiff.so
/usr/lib/x86_64-linux-gnu/libtiff.so

boost and las.so not required here, i think

Thanks but no success here.

On Fri, May 23, 2014 at 10:04 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:

On Fri, May 23, 2014 at 3:35 PM, Rashad M <mohammedrashadkm@gmail.com>
wrote:

Hi Vaclav,

If it helps: http://trac.osgeo.org/grass/ticket/2065

Thanks, I tried to unify the variables (r57541 and the patch from
#2065):

CFLAGS="$CFLAGS $LIBLAS_CFLAGS $LIBLAS_INC"
CPPFLAGS="$CPPFLAGS $LIBLAS_CPPFLAGS $LIBLAS_INC"

but it did not help. I see that the ticket is closed and it puzzles me
that it is not enough for me.

On Fri, May 23, 2014 at 9:25 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:

On Fri, May 23, 2014 at 2:53 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Vaclav Petras wrote:

> So the test failed with segmentation fault

Possibly due to linking with gcc rather than g++. But that doesn't
matter, as configure tests don't normally try to execute the program
(that doesn't work if you're cross-compiling); they only care
whether
linking succeeds.

I have to remember this gcc vs g++ possible issue and that ./cofigure
does not execute. However, it did not helped me now. My sample program still
segfaults when compiled with g++.

I've tried also cxxflags and a file with cpp extension:

g++ liblastest.cpp -o liblastest -ggdb $(liblas-config --libs)
$(liblas-config --includes) $(liblas-config --cxxflags)

but it still segfaults (with and without -ggdb). Should I report this
somewhere (Launchpad, libLAS)?

> but it would actually fail
> during compilation if I would use `liblas-config --libs` because
> the boost
> libraries are `libboost_program_options.so.1.54.0` on my computer
> while
> `liblas-config --libs` says just `libboost_program_options.so`
> (same for
> thread library).

You may need to install a -devel package, e.g. boost-devel or
whatever.

Typically, the unversioned symlink is in the -devel package, as it's
only needed for compiling programs which use the library; running
them
will use either the library itself or a symlink which includes at
least the major version number.

I installed libboost-thread-dev and libboost-program-options-dev and
compilation works with $(liblas-config --libs) $(liblas-config --includes).
So, it should work in ./configure but the result is still "libLAS support:
no".

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Regards,
   Rashad

--
Regards,
   Rashad

--
Regards,
   Rashad

--
Regards,
   Rashad

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

wenzeslaus · May 30, 2014, 2:00pm

On Thu, May 29, 2014 at 1:09 PM, Javier Martínez-López <
javi.martinez.lopez@gmail.com> wrote:

Hi,

I had the same problem with the latest grass 71 svn version (from
today) under ubuntu 14.04 and I certainly solved it installing
libboost-all-dev and the config option: --with-liblas=yes
--with-liblas-config=/usr/bin/liblas-config

Thank you. This was very helpful. The problem was that I included only

--with-liblas-config=/usr/bin/liblas-config

in my ./configure call. I thought that this is enough. When I added

--with-liblas=yes

it started to work. After ./configure ... && make, I have r.in.lidar and
v.in.lidar.

I still have just libboost-thread-dev and libboost-program-options-dev, the
libboost-all-dev package is not necessary, although it is the simplest
option.

I don't understand the think with --with-liblas=yes, I really though I read
here that it is not necessary (once you have --with-liblas-config) and Yann
was saying that different combinations of --with-liblas* does not work for
him.

There is still the problem with different content of CFLAGS and CPPFLAGS
variables (r57541 and the patch from #2065) in ./configure and also I'm not
able to run the test program from ./configure myself. I don't know how this
is important.

Thanks all for help. I'll try this also on other computers with Ubuntu
14.04 and I'll let you know if it will not work.

Vaclav

On Thu, May 22, 2014 at 3:25 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

I was trying to compile GRASS with libLAS but ./configure says no.

I used:

--with-liblas-config=/usr/bin/liblas-config

and I have all liblas packages from standard Ubuntu 14.04 repository

(libLAS version is 1.7.0 which is the current stable release).

On Thu, May 22, 2014 at 8:47 PM, Yann Chemin <ychemin@gmail.com> wrote:

I can confirm the issue,

also by trying these configure options it is not helping:
--with-liblas --with-liblas-config
--with-liblas --with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes --with-liblas-config
--with-liblas=yes --with-liblas-config=/usr/bin/liblas-config

Also two targets are found, both valid (v1.7.0) and identical:
whereis liblas-config
liblas-config: /usr/bin/liblas-config /usr/bin/X11/liblas-config
/usr/share/man/man1/liblas-config.1.gz

$ ls -aslh /usr/bin/X11/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/X11/liblas-config
$ ls -aslh /usr/bin/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/liblas-config

Yann4 · May 31, 2014, 6:01am

Hi,

I have libboost-thread-dev, libboost-program-options-dev, and
libboost-all-dev installed
in configure options: --with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes

still:
checking whether to use libLAS... yes
checking for liblas-config... /usr/bin/liblas-config
configure: error: *** Unable to locate libLAS library.

Full config script:
CFLAGS="-g -Wall"
./configure --with-cxx --with-wxwidgets --with-freetype=yes
--with-postgres=no --with-sqlite=yes --without-tcltk
--enable-largefile=yes --with-freetype-includes=/usr/include/freetype2
--with-opengl-libs=/usr/include/GL --with-readline --with-python=yes
--with-lapack --with-gdal=/usr/bin/gdal-config
--with-proj-share=/usr/share/proj --with-pthread
--with-liblas-config=/usr/bin/liblas-config --with-liblas=yes
--with-blas

On 30/05/2014, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Thu, May 29, 2014 at 1:09 PM, Javier Martínez-López <
javi.martinez.lopez@gmail.com> wrote:

Hi,

I had the same problem with the latest grass 71 svn version (from
today) under ubuntu 14.04 and I certainly solved it installing
libboost-all-dev and the config option: --with-liblas=yes
--with-liblas-config=/usr/bin/liblas-config

Thank you. This was very helpful. The problem was that I included only

--with-liblas-config=/usr/bin/liblas-config

in my ./configure call. I thought that this is enough. When I added

--with-liblas=yes

it started to work. After ./configure ... && make, I have r.in.lidar and
v.in.lidar.

I still have just libboost-thread-dev and libboost-program-options-dev, the
libboost-all-dev package is not necessary, although it is the simplest
option.

I don't understand the think with --with-liblas=yes, I really though I read
here that it is not necessary (once you have --with-liblas-config) and Yann
was saying that different combinations of --with-liblas* does not work for
him.

There is still the problem with different content of CFLAGS and CPPFLAGS
variables (r57541 and the patch from #2065) in ./configure and also I'm not
able to run the test program from ./configure myself. I don't know how this
is important.

Thanks all for help. I'll try this also on other computers with Ubuntu
14.04 and I'll let you know if it will not work.

Vaclav

On Thu, May 22, 2014 at 3:25 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:

I was trying to compile GRASS with libLAS but ./configure says no.

I used:

--with-liblas-config=/usr/bin/liblas-config

and I have all liblas packages from standard Ubuntu 14.04 repository

(libLAS version is 1.7.0 which is the current stable release).

On Thu, May 22, 2014 at 8:47 PM, Yann Chemin <ychemin@gmail.com> wrote:

I can confirm the issue,

also by trying these configure options it is not helping:
--with-liblas --with-liblas-config
--with-liblas --with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes --with-liblas-config
--with-liblas=yes --with-liblas-config=/usr/bin/liblas-config

Also two targets are found, both valid (v1.7.0) and identical:
whereis liblas-config
liblas-config: /usr/bin/liblas-config /usr/bin/X11/liblas-config
/usr/share/man/man1/liblas-config.1.gz

$ ls -aslh /usr/bin/X11/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/X11/liblas-config
$ ls -aslh /usr/bin/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/liblas-config

--
----

Yann4 · May 31, 2014, 1:23pm

More from config.log (thx MarkusM)

configure:6198: checking whether to use libLAS
configure:6215: checking for liblas-config
configure:6272: gcc -o conftest -g -O2 -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -I/usr/include -I/usr/include/gdal
-I/usr/include/geotiff -I/usr/include/x86_64-linux-gnu
-Wl,--export-dynamic conftest.c -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/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so 1>&5
configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or directory
#include <liblas/capi/liblas.h>
^
compilation terminated.
configure: failed program was:
#line 6265 "configure"
#include "confdefs.h"
#include <liblas/capi/liblas.h>
int main() {
LASReader_Create("foo");
; return 0; }
configure:6287: gcc -o conftest -g -O2 -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -I/usr/include -I/usr/include/gdal
-I/usr/include/geotiff -I/usr/include/x86_64-linux-gnu
-Wl,--export-dynamic conftest.c -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/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so 1>&5
configure:6281:32: fatal error: liblas/capi/liblas.h: No such file or directory
#include <liblas/capi/liblas.h>
^
compilation terminated.
configure: failed program was:
#line 6280 "configure"
#include "confdefs.h"
#include <liblas/capi/liblas.h>
int main() {
LASReader_Create("foo");
; return 0; }

On 31/05/2014, Yann Chemin <ychemin@gmail.com> wrote:

Hi,

I have libboost-thread-dev, libboost-program-options-dev, and
libboost-all-dev installed
in configure options: --with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes

still:
checking whether to use libLAS... yes
checking for liblas-config... /usr/bin/liblas-config
configure: error: *** Unable to locate libLAS library.

Full config script:
CFLAGS="-g -Wall"
./configure --with-cxx --with-wxwidgets --with-freetype=yes
--with-postgres=no --with-sqlite=yes --without-tcltk
--enable-largefile=yes --with-freetype-includes=/usr/include/freetype2
--with-opengl-libs=/usr/include/GL --with-readline --with-python=yes
--with-lapack --with-gdal=/usr/bin/gdal-config
--with-proj-share=/usr/share/proj --with-pthread
--with-liblas-config=/usr/bin/liblas-config --with-liblas=yes
--with-blas

On 30/05/2014, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Thu, May 29, 2014 at 1:09 PM, Javier Martínez-López <
javi.martinez.lopez@gmail.com> wrote:

Hi,

I had the same problem with the latest grass 71 svn version (from
today) under ubuntu 14.04 and I certainly solved it installing
libboost-all-dev and the config option: --with-liblas=yes
--with-liblas-config=/usr/bin/liblas-config

Thank you. This was very helpful. The problem was that I included only

--with-liblas-config=/usr/bin/liblas-config

in my ./configure call. I thought that this is enough. When I added

--with-liblas=yes

it started to work. After ./configure ... && make, I have r.in.lidar and
v.in.lidar.

I still have just libboost-thread-dev and libboost-program-options-dev,
the
libboost-all-dev package is not necessary, although it is the simplest
option.

I don't understand the think with --with-liblas=yes, I really though I
read
here that it is not necessary (once you have --with-liblas-config) and
Yann
was saying that different combinations of --with-liblas* does not work
for
him.

There is still the problem with different content of CFLAGS and CPPFLAGS
variables (r57541 and the patch from #2065) in ./configure and also I'm
not
able to run the test program from ./configure myself. I don't know how
this
is important.

Thanks all for help. I'll try this also on other computers with Ubuntu
14.04 and I'll let you know if it will not work.

Vaclav

On Thu, May 22, 2014 at 3:25 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:

I was trying to compile GRASS with libLAS but ./configure says no.

I used:

--with-liblas-config=/usr/bin/liblas-config

and I have all liblas packages from standard Ubuntu 14.04 repository

(libLAS version is 1.7.0 which is the current stable release).

On Thu, May 22, 2014 at 8:47 PM, Yann Chemin <ychemin@gmail.com> wrote:

I can confirm the issue,

also by trying these configure options it is not helping:
--with-liblas --with-liblas-config
--with-liblas --with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes --with-liblas-config
--with-liblas=yes --with-liblas-config=/usr/bin/liblas-config

Also two targets are found, both valid (v1.7.0) and identical:
whereis liblas-config
liblas-config: /usr/bin/liblas-config /usr/bin/X11/liblas-config
/usr/share/man/man1/liblas-config.1.gz

$ ls -aslh /usr/bin/X11/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/X11/liblas-config
$ ls -aslh /usr/bin/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/liblas-config

--
----

--
----

wenzeslaus · May 31, 2014, 1:27pm

On Sat, May 31, 2014 at 9:23 AM, Yann Chemin <ychemin@gmail.com> wrote:

configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or
directory
#include <liblas/capi/liblas.h>

Hm, are you sure you have the liblas-c-dev package? And are you sure the
file liblas/capi/liblas.h is there (on include path, in case of the
liblas-c-dev package it should be /usr/include/liblas/capi/liblas.h)?

Yann4 · May 31, 2014, 1:32pm

OK it was that thanks Vaclav

Summary:
sudo apt-get install libboost-thread-dev,libboost-program-options-dev
liblas-c-dev

in configure options:
--with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes

On 31/05/2014, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Sat, May 31, 2014 at 9:23 AM, Yann Chemin <ychemin@gmail.com> wrote:

configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or
directory
#include <liblas/capi/liblas.h>

Hm, are you sure you have the liblas-c-dev package? And are you sure the
file liblas/capi/liblas.h is there (on include path, in case of the
liblas-c-dev package it should be /usr/include/liblas/capi/liblas.h)?

--
----

wenzeslaus · May 31, 2014, 1:56pm

On Sat, May 31, 2014 at 9:32 AM, Yann Chemin <ychemin@gmail.com> wrote:

OK it was that thanks Vaclav

Summary:
sudo apt-get install libboost-thread-dev,libboost-program-options-dev
liblas-c-dev

in configure options:
--with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes

I updated the wiki for 14.04 and added libLAS packages and added libLAS to

configure for GRASS 7. I think the page needs some refactoring. I have hard
time to navigate it when I understand most of the terms but the problem is
the high number of possibilities.

http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu

On 31/05/2014, Vaclav Petras <wenzeslaus@gmail.com> wrote:
> On Sat, May 31, 2014 at 9:23 AM, Yann Chemin <ychemin@gmail.com> wrote:
>
>> configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or
>> directory
>> #include <liblas/capi/liblas.h>
>>
>
> Hm, are you sure you have the liblas-c-dev package? And are you sure the
> file liblas/capi/liblas.h is there (on include path, in case of the
> liblas-c-dev package it should be /usr/include/liblas/capi/liblas.h)?
>

--
----

Yann4 · May 31, 2014, 2:26pm

Looking into the Wiki page I got FFMPEG configured by this:

sudo apt-get install libffms2-dev

and from wiki page:

--with-ffmpeg=yes \
--with-ffmpeg-includes="/usr/include/libavcodec
/usr/include/libavformat /usr/include/libswscale
/usr/include/libavutil"

On 31/05/2014, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Sat, May 31, 2014 at 9:32 AM, Yann Chemin <ychemin@gmail.com> wrote:

OK it was that thanks Vaclav

Summary:
sudo apt-get install libboost-thread-dev,libboost-program-options-dev
liblas-c-dev

in configure options:
--with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes

I updated the wiki for 14.04 and added libLAS packages and added libLAS
to

configure for GRASS 7. I think the page needs some refactoring. I have hard
time to navigate it when I understand most of the terms but the problem is
the high number of possibilities.

http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu

On 31/05/2014, Vaclav Petras <wenzeslaus@gmail.com> wrote:
> On Sat, May 31, 2014 at 9:23 AM, Yann Chemin <ychemin@gmail.com> wrote:
>
>> configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or
>> directory
>> #include <liblas/capi/liblas.h>
>>
>
> Hm, are you sure you have the liblas-c-dev package? And are you sure
> the
> file liblas/capi/liblas.h is there (on include path, in case of the
> liblas-c-dev package it should be /usr/include/liblas/capi/liblas.h)?
>

--
----

--
----