Can't read LAS on Jammy

[phma]

I have two Linux boxes, one running Focal and one running Jammy. CloudCompare on Focal uses PDAL to read LAS files, as shown by these lines from ldd:

Code: Select all

libpdal_base.so.9 => /lib/libpdal_base.so.9 (0x00007fc71cabc000)
libpdal_util.so.9 => /lib/libpdal_util.so.9 (0x00007fc71ca91000)

I know it uses PDAL to read LAS, because I once found a bug in PDAL by reading a malformed LAS file with CloudCompare. CloudCompare on Jammy, though, does not read LAS files, even though version 13 is installed and has the corresponding so files. I cloned the repo and built it on Jammy, but the one I build doesn't read LAS files either. How can I build CloudCompare that reads LAS files?

[daniel]

The latest version of CloudCompare (2.13) relies on LASzip. Make sure you enable the PLUGIN_IO_QLAS option in CMake (and disable PDAL or LAS_FWF)

[phma]

I did that, and it built the plugin, but when I run CloudCompare, it doesn't find it.

Code: Select all

phma@mooncat:~/build/CloudCompare/grel$ ninja install
...
-- Up-to-date: /home/phma/.local/lib/cloudcompare/plugins/libQCORE_IO_PLUGIN.so
-- Up-to-date: /home/phma/.local/lib/cloudcompare/plugins/libQLAS_IO_PLUGIN.so

However, where it looks for the plugins is /home/phma/.local/share/CCCorp/CloudCompare/plugins . How do I fix it?

[daniel]

Hum, not sure, but I guess this is controlled somewhere in https://github.com/CloudCompare/CloudCo ... r.cpp#L284?

[phma]

Is there a CMake flag that controls where it installs the plugins or where it looks for them?

[daniel]

No, but maybe a Qt flag? https://stackoverflow.com/questions/512 ... ms-to-fail

[phma]

QT_PLUGIN_PATH isn't set, so there shouldn't be a problem with finding the plugin. Also, that post is about Python on Windows, so it's irrelevant to a C++ program on Linux.

Code: Select all

phma@mooncat:~/src/CloudCompare$ find . |xargs grep CCCorp 2>/dev/null
./libs/CCAppCommon/src/ccApplicationBase.cpp:   setOrganizationName("CCCorp");
./plugins/core/Standard/qJSonRPCPlugin/README.md:- /home/username/.local/share/CCCorp/CloudCompare/plugins
./plugins/core/Standard/qJSonRPCPlugin/README.md:- /usr/local/share/CCCorp/CloudCompare/plugins
./plugins/core/Standard/qJSonRPCPlugin/README.md:- /usr/share/CCCorp/CloudCompare/plugins
./plugins/core/Standard/qJSonRPCPlugin/README.md:- /var/lib/snapd/desktop/CCCorp/CloudCompare/plugins
./plugins/core/Standard/qJSonRPCPlugin/README.md:ln -s build-CloudCompare-Desktop-Debug/plugins/core/Standard/qJSonRPCPlugin/libQJSON_RPC_PLUGINd.so ~/.local/share/CCCorp/CloudCompare/plugins/libQJSON_RPC_PLUGINd.so

This suggests that the search directory with "CCCorp" is correct, and the directory where the plugins are actually installed is wrong. The README file suggests a link; I'll see if I can link the directory and make it find it.

Another problem is that both PDAL and LASzip are removed from bookworm (the next release of Debian). See https://bugs.debian.org/cgi-bin/pkgrepo ... oudcompare . This doesn't affect Jammy, which was already released, but in the future, how can CloudCompare read LAS files? If there's nothing else, I've written code to read and write LAS files independently of PDAL and LASzip.

[daniel]

I'm not sure about the plugin path/search, as I was not involved in the development of this part (Andy Maloney did it, maybe you could try your luck on Github, declaring an issue, and explicitly adding him to the discussion).

And for Debian removing both PDAL and LASzip... well... I'm not sure what they are trying to achieve this way, but that's a bummer for their users. Once again, you could start a discussion on github, and maybe include Thomas Montaigu for instance (he is the developer of the newest plugin relying on LASzip - which works really well now ;).