CloudCompare forum

Hi everybody, i would like to thank you for this great tool. i am a geologist working with TLS-acquired point clouds and i just tried qCC on gentoo linux. Sources compiled fine but i have some problems loading ply files:

qCC/fileIO/rply.c:1223: ply_type_check: Asserzione `sizeof(long) == 4' fallita.

Trying to comment out the size checks in rply.c makes the code correctly work but i think this is not a good option.
Checking size of long type on my system in this way:

using namespace std;
int main (int argc, char **argv){
int ecco = sizeof(long);
cout << ecco << endl;
}

resulted in a long's size of 8, not 4.
I think this depend upon my arch that is 64bit.

Any suggestions on how to correct this behavior? I could eventually send back a patch if someone have hints on this error.

Note: code compiled with gcc-4.5.3 on gentoo-linux system arch x86_64



Luca Penasa

Indeed, the fact that "long" corresponds to 64 bits is quite troublesome. It appears to be one of the major pitfalls that is encountered when porting 32 bits C++ code to 64 bits (http://www.viva64.com/en/a/0004).

The "long" symbol is seldom used in CloudCompare (it's used however by several libraries such as 'triangle' and 'quick hull'). So for the moment, you could simply replace all "long" occurrences by "int" (or even "int32_t" on Linux?) in rply files (rply.h and rply.c) and of course "PlyFilter.cpp".

Eventually, I know that a proper "portage" to 64 bits has been done at EDF R&D and I'm currently trying to get more info on this. Meanwhile, any feedback on this subject would be very valuable.


P.S. : I hope that "unsigned" still corresponds to a 32 bits integer? Otherwise you'll have the same problem with a lot of pieces of CloudCompare code!

Daniel

So for the moment, you could simply replace all "long" occurrences by "int"

Il will try this solution for the moment...

On the net there are many pages on the subject:
http://developers.sun.com/solaris/artic ... ssues.html
http://www.ibm.com/developerworks/libra ... index.html

"unsigned" still corresponds to a 32 bits integer?

I don't know that, i never worked on these problems, but i think the int sizes were not touched so it should not raise any problem.