cmake compilation

[ndavid]

Hi

If you're interested, I've written some CMakelists and cmake module in order to compile lag && lidarquatree.

• It has been tested on ubuntu 12.10 and debian testing.
• it find lastools automatically if downloaded next to lag
• in order to not conflict with other liblas It need that lastools/liblas.a must be rename liblaslib.a
• README.md have been updated with some cmake instruction (not yet complete, lack some image)

Nicolas David

[ada-foss]

That's interesting. The automake setup that LAG has was never done propperly in the first place, but for the life of me, I can't work out how it's supposed to be. I'm looking at cmake now, and it seems quite reasonably documented at a glance.

I did not manage to compile with cmake yet, as I actually have a different setup for laslib. There's a long story to that, but the short version is that I've now got a folder called lastools-patched in the testing branch, this has some handwritten makefiles to build laslib and install it as a dynamic linkable, complete with relevant pkg-config file.

Would you mind taking a look at the testing branch and see if you can get it to play with the dynamic linkable instead? (Or just give me some pointers on what I need to do to do that myself.) Would it be possible to make the build process support both versions?

[ndavid]

I've updated my lag fork with an up-to-date testing branch and I've added some laslib compilation support within the cmake project. Cmake project now support

• choice between external/internal laslib link (default is internal )
• choice between static/shared compilation for internal laslib (default is shared )
• when internally compiled laslib is installed with make install (default path to /usr/local)

So the basics steps for compilation are now:

$ cd path/toLag/
$ mkdir build_lag
$ cd build_lag
$ cmake-gui ../ 

• choose your configure/compilations options within cmake-gui then clic on "generate"

$ make
$ sudo make install

I've created laslib compilation from scratch as I could not find any makefile on the lastools-patched directory. There is still room for cmake improvement.

• liblidarquatree is still only statically compiled/Linked.
• liblidarquatree /lag could also be added to "install" target
• ...

[ada-foss]

Ok, so, I have finally gotten around to looking through and giving this a whirl. Compiling was awesomely easy, though there was quite a few warnings from LASlib that I probably wont ever do anything about.

However, the bit I was worried about turned out not to work. My compilation segfaults when attempting to load a file. The backtrace is here:

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00000000004d33d1 in LASreader::read_point() ()
#2  0x00000000004cf769 in LoadWorker::load_points(Quadtree*) ()
#3  0x00000000004d09db in LoadWorker::run() ()
#4  0x00000000004894c4 in sigc::bound_mem_functor0<void, Worker>::operator()() const ()
#5  0x0000000000488e18 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, Worker> >::operator()() const ()
#6  0x00000000004883ff in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, Worker>, void>::call_it(sigc::internal::slot_rep*) ()
#7  0x0000003230a428dd in ?? () from /lib64/libglibmm-2.4.so.1
#8  0x000000307b46a305 in ?? () from /lib64/libglib-2.0.so.0
#9  0x0000003079c07d14 in start_thread () from /lib64/libpthread.so.0
#10 0x00000030798f167d in clone () from /lib64/libc.so.6

I tried both static and shared builds of LASlib and achieved the same results. Any ideas? Is this liable to fail due to my pre-existing build of LASlib? I could try this from a clean VM if you think it would help.

[ndavid]

First concerning LASlib warning

• I have added -Wno-strict-aliasing compiler flags in order to suppres a lot of warnings but it's quite dirty, because it's hide a possible undefined behaviour of laslib code.
• I have not added -Wunused-but-set-variable compiler flags because there are less warnings of this type but it could be added to remove all laslib warnings
• It could be quite dangerous to remove warning because then often indicate wrong use of c++ features that could be lead to undefined behaviour.

About segfault

Unfortunately loading las file works quite fine for me so I can't reproduce your bug. What is your gnu/linux distribution ?

But from your backtrace it's seems like read_point() from laslib is pointing toward a null function. So I think error should be related to laslib. I think error could be due to the use of existing lasreader.hpp file on your standard include path (/usr/include, /usr/local/include) but linking with the internal lastool-patched library.

So for debugguing purpose could you run some command line :

• ldd lag |grep -e"liblas"
• nm -g lag |grep -e"LASreader.*read_point"

Could-you also test compilation after uninstalling all laslib stuff on /usr directory ?

• locate -b 'lasreader.hpp'

And last perhaps it's could help to compile/run lag with debug build (with cmake-gui you could manually set CMAKE_BUILD_TYPE to Debug)

Hope it will help.

[ada-foss]

The LASlib warnings are most likely an upstream problem, so I wont fix those for now, as anything I do to the LASlib code might get overwritten and I'll be forever merging conflicts every LASlib update.

I will look deeper into my segfault issue soon, but what you're saying sounds about right and I think I've had problems like that before, too. I'm working on an extremely modified Fedora17 system.

[ada-foss]

This has been on top of my to-do list for quite a while with LAG, and since looking at it I've gone away and done some substantial work on another project which has ended up taking up a few months of time. In that time LASlib's changed quite a lot, and I've been keeping up with the makefiles just about, but it looks like this patch hasn't been.

I still don't really understand cmake, and I'm not sure what I can do to maintain this. If you're still interested, can you get in touch with me to discuss the newer version of LASlib and updating the cmakefiles? If this is done reasonably promptly then I can have a bash at testing the new version before I finish working here. After that, I don't know what I will do, but it will probably fall to the next maintainer.