[Load] Can't guess file format: unhandled file extension 'XXX'

[PabloC]

Hi.

I'm on an ArchLinux computer and I updated my distro this morning (including Qt I guess).
I'm not able to load any file in CloudCompare anymore.

Don't know if it's related but neither a brand new clone nor my development version can now load files.

PS: I'm using regular ASCII files at the moment.

[daniel]

Hi Pablo,

Many problems have occurred with ArchLinux recently...

Is it happening when dropping a file on the 3D view, or even when you use the loading dialog and specify a specific file filter?

Can you maybe run CC in debug mode and trace into "FileIOFilter::LoadFromFile"?

[PabloC]

Hi Pablo,

Many problems have occurred with ArchLinux recently...

Is it happening when dropping a file on the 3D view, or even when you use the loading dialog and specify a specific file filter?

Can you maybe run CC in debug mode and trace into "FileIOFilter::LoadFromFile"?

Same behavior for both the drag-and-drop and the QDialog window.
Thanks for the hint, I'll give a look at FileIOFilter::LoadFromFile and come back.

[PabloC]

Can't find what's wrong for now.
It works fine with a fresh clone using an up-to-date KUbuntu.

EDIT : the main difference here is that there are format filters on the *buntu distros and they're not here anymore using the ArchLinux. As far as my understanding of the process goes, you rely on the file extension to select a loading algorithm. But without any enxtension hint, CC just gives up on this selection step.

[daniel]

Interesting... The default file 'filters' are loaded at startup time (see main.cpp, line 229):

Code: Select all

	FileIOFilter::InitInternalFilters(); //load all known I/O filters (plugins will come later!)

The InitInternalFilters method simply creates the I/O filters (ASCII, BIN, LAS, etc.) and registers them in a singleton container.

Maybe this singleton is not correctly accessed by the main application (as it's created in the QCC_IO_LIB library) but it shouldn't be an issue as the QCC_IO_LIB is statically linked...

[PabloC]

All right, here is the solution I found :

Code: Select all

cd path/to/cc
mkdir build 
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=~/.local
make install

Here, everything works as expected.
But when in need of the Debug version :

Code: Select all

cmake .. -DCMAKE_BUILD_TYPE=Debug
make install

And here, CC does not have the filters and does not allow me to open files.
Next :

Code: Select all

rm -rf ~/.local/lib/everythingLinkedToCC
make install

Then, CC works as expected.
In the end it's just that the install process does not replace the required libraries when switching the CMAKE_BUILD_TYPE field.
So, nothing Qt related in this issue.

EDIT :
I tried to build+install in Release mode, start CC, build+install in Debug mode and start CC on a *buntu and got no issue.
So it could come from CMake on Arch or anything else in the universe.

Conclusion for Arch users : manually clear the libs while switching the CMAKE_BUILD_TYPE solve this issue.

[daniel]

I don't know how it works on Linux: does the libraries have the same name in debug and release modes? Are they output in the same folder?

On Windows (with Visual Studio or code::blocks) the release and debug configurations are different, and generally the library names also. Therefore we don't have this kind of issue.

[PabloC]

Hi Daniel.

Debug and Release libs both go in the same directory.
The only difference is the 'd' at the end of the file name in debug mode.

As a short term solution I use this command :

Code: Select all

[ ! -f install_manifest.txt ] || xargs rm < install_manifest.txt

It removes every previously installed files (listed in the install_manifest.txt file which is CMake generated) on my system before reinstalling the updated ones.
It's equivalent to some kind of

Code: Select all

make unsintall