GCC-4.0.x Issues Internal Cmod conversion problem solved?

[cartrite]

This has to do with a build on Suse 10 x86_64 gcc-4.0.2 of all versions of celestia with all gui's.

Any dectectives out there.
When I run celestia and goto a model, The verbose on the screen says the model loads and the texture loads without errors. An ascii cmod model is visible and a binary cmod model is invisable. From what I think I understand from the code the ascii model is converted to binary in modelfile.cpp. Since cmods are visable when celestia converts them to binary but not visable when no conversion is needed something is going wrong with the cmod file that dosen't need to be converted but is still missing all the error checks. But what.

cartrite

[chris]

This has to do with a build on Suse 10 x86_64 gcc-4.0.2 of all versions of celestia with all gui's.

You're running a 64-bit OS? It's my guess that there's something wrong with the binary cmod reader on 64-bit machines. Somewhere in the code, there's probably an assumption that the size of an integer is 32 bits. Code that reads binary data from a file tends to be more prone to this sort of bug than code that reads ASCII files.

--Chris

[chris]

I'm fairly certain I know exactly where the problem is . . . I'll check in the very simple fix later today.

--Chris

[cartrite]

Thanks Chris, I wouldn't know were to start.

cartrite

[chris]

I checked in what I think is a fix, but I don't have a 64-bit Linux system to test it out on. The change is very small and touches just the file modelfile.cpp. Here's the diff:

Code: Select all

1082c1082
<     int i = readUint(in);
---
>     uint32 i = readUint(in);


Please let me know if you can view binary cmod files after applying this patch.

--Chris

[cartrite]

Hi Chris,

Sorry to say it doesn't. I only know enough about c++ to be dangerous but I've been looking at this all day and it seems like there would be a lot of work here. At first I thought that the ascii files were converted to binary but from what I think I see they are treated differently and end up with different structures.

Am I right here?

Code: Select all

Is file ascii? yes > ASCII reader > ASCII writer return / or is it binary? > Binary > Binary writer > return

I may be wrong but I was looking into the bytes.h, and byteswap.h to name a few???

Also my output while building has the following warnings while building modelfile.cpp:

Code: Select all

model.cpp:31: warning: ?€?VertexAttributeFormatSizes?€™ defined but not used
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I..  -DQT_THREAD_SUPPORT  -D_REENTRANT  -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common  -I/usr/X11R6/include/GL -O2 -Wall -ffast-math -fexpensive-optimizations -fomit-frame-pointer  -MT modelfile.o -MD -MP -MF ".deps/modelfile.Tpo" \
  -c -o modelfile.o `test -f 'modelfile.cpp' || echo './'`modelfile.cpp; \
then mv -f ".deps/modelfile.Tpo" ".deps/modelfile.Po"; \
else rm -f ".deps/modelfile.Tpo"; exit 1; \
fi
model.h:73: warning: ?€?class Model::MeshComparator?€™ has virtual functions but non-virtual destructor
model.h:91: warning: ?€?class Model::OpacityComparator?€™ has virtual functions but non-virtual destructor
modelfile.cpp: In member function ?€?char* AsciiModelLoader::loadVertices(const Mesh::VertexDescription&, uint32&)?€™:
modelfile.cpp:525: warning: unused variable ?€?nBytes?€™
modelfile.cpp: In member function ?€?char* BinaryModelLoader::loadVertices(const Mesh::VertexDescription&, uint32&)?€™:
modelfile.cpp:1533: warning: unused variable ?€?readCount?€™

Does anyone else with a 64 bit OS have similar problems??

cartrite

[cartrite]

I ??Think?? I found a workaround. If you pass the option

Code: Select all

CXXFLAGS=-fno-strict-aliasing

to the configure options and build it the binary cmod files work.
I found this on the following page.
http://gcc.gnu.org/bugs.html#known

It's about half way down the page.

This probally had a lot to do with gcc-4.0.2 and not the x86_64 platform.

cartrite

[t00fri]

I ??Think?? I found a workaround. If you pass the option

Code: Select all

CXXFLAGS=-fno-strict-aliasing

to the configure options and build it the binary cmod files work.
I found this on the following page.
http://gcc.gnu.org/bugs.html#known

It's about half way down the page.

This probally had a lot to do with gcc-4.0.2 and not the x86_64 platform.

cartrite

Wow, cartrite, you must have been working hard on this!

Bye Fridger

[cartrite]

A couple of days. The hard part was trying to figure out if I configured my new Suse OS wrong. Or What? I got a lot more problems that have nothing to do with Celestia.

I got more familiar with the code though.

Time for a beer.

cartrite

[cartrite]

I renamed this topic to ..........??(solved) because although this workaround allows binary cmods to be seen, I'm not sure what other damage it may cause. Haven't seen anything yet. Time will tell. If one looks at the gcc page where I found this workaround it kinda strikes fear into me as far as the state of the present code standards. I don't really know though.
later,
cartrite

[Boux]

I ??Think?? I found a workaround. If you pass the option

Code: Select all

CXXFLAGS=-fno-strict-aliasing

to the configure options and build it the binary cmod files work.
I found this on the following page.
http://gcc.gnu.org/bugs.html#known

It's about half way down the page.

This probally had a lot to do with gcc-4.0.2 and not the x86_64 platform.

cartrite

Cartrite,
I no longer browse these forums very often and I just read your post.
You can do that way but the side effect of passing directly the option to configure may be that you are overriding your global compiler environment with less than optimal optimization.
My 2 cents on this but I believe the proper way to do it is to pass a new environment string to the system.
Actually it is how I compile Celestia on my Mandriva GCC 4.+.+ P4 machine, with thorough optimisations for speed, without killing stability:

First:

Code: Select all

export CFLAGS="-fno-strict-aliasing -O3 -march=pentium4 -fomit-frame-pointer -pipe -fprefetch-loop-arrays -funroll-loops -ffast-math"


Second:

Code: Select all

CXXFLAGS=$CFLAGS


Then, as usual:

Code: Select all

./configure --with-kde --with-lua --disable-debug
make


The -march option has to be changed according to your processor.
Other options according to your environment.
I would be much interested in your results.

I came to this solution some months ago, when no developper on this board was interested in the "binary cmod models not showing" issue/bug when compiling with GCC.4.+.+.

[cartrite]

Hi Boux,

Actually, I think I ended up adding that option to one of the make files in the admin folder.
I'll try your method and report any changes that I notice.

edit: Not the admin folder. I can't remember but I think I found how to (syntax) from the configure script. Then I just added the option on the command line. Anyhow I'll let you know.
Give me a few days so I can notice if there are any changes.

cartrite

[cartrite]

Due to my inexpierience at setting system variables I will not be trying this. I am currently going thru a system meltdown of suse 10 and will consider myself lucky if I can recover the files that were on that system at the time of the crash. So I don't want to play games with something I know little about. SORRY

Edit: I did recover. But I need more time to look into what I can change and what I can't. My system meltdown had nothing to do with this.

cartrite

[John Van Vliet]

hi i was looking into this today , tonight i say this post
this is the make output and i noticed this bit

Code: Select all

  -c -o modelfile.o `test -f 'modelfile.cpp' || echo './'`modelfile.cpp; \
then mv -f ".deps/modelfile.Tpo" ".deps/modelfile.Po"; \
else rm -f ".deps/modelfile.Tpo"; exit 1; \
fi
model.h:73: warning: ?€?class Model::MeshComparator?€™ has virtual functions but non-virtual destructor
model.h:91: warning: ?€?class Model::OpacityComparator?€™ has virtual functions but non-virtual destructor
modelfile.cpp: In member function ?€?char* AsciiModelLoader::loadVertices(const Mesh::VertexDescription&, uint32&)?€™:
modelfile.cpp:525: warning: unused variable ?€?nBytes?€™
modelfile.cpp: In member function ?€?Mesh* AsciiModelLoader::loadMesh()?€™:
modelfile.cpp:625: warning: negative integer implicitly converted to unsigned type
modelfile.cpp: In function ?€?float readFloat(std::istream&)?€™:
modelfile.cpp:1083: warning: dereferencing type-punned pointer will break strict-aliasing rules
modelfile.cpp: In member function ?€?char* BinaryModelLoader::loadVertices(const Mesh::VertexDescription&, uint32&)?€™:
modelfile.cpp:1533: warning: unused variable ?€?readCount?€™

and this was the bug i say

Code: Select all

modelfile.cpp: In function ?€?float readFloat(std::istream&)?€™:
modelfile.cpp:1083: warning: dereferencing type-punned pointer will break strict-aliasing rules

i will go and give the work around a try as soon as i log-off

my OS is Fedora5 32bit

[cartrite]

That looks like the same warnings I was getting. I just passed the

Code: Select all

CXXFLAGS=-fno-strict-aliasing

to ./configure

When I tried Boux's method I ran into my limit of knowledge. I don't know all the flags to put in. I got a configure error that gcc could not open the output file. I was also having other problems so I gave up. The ASCII mode files work without doing anything.

cartrite

[John Van Vliet]

after adding chris's fix it was still a no-go but also adding
CXXFLAGS=-fno-strict-aliasing
cmod's are now working
for gcc 4.1.1-1

but it might be nice if a change to star.h is added to cvs

Code: Select all

line # 33

    StarDetails::StarDetails();

to

    //StarDetails:://
StarDetails();


and to command.h

Code: Select all


line # 97

    CommandGotoLongLat::CommandGotoLongLat(double t,

to

   // CommandGotoLongLat:://
CommandGotoLongLat(double t,



i get build errors without thease changes

[karsten]

i can confirm that this works perfectly for this problem on SuSE 10.1 x86_64. I can now view moons that I couldn't see before. (Phobos, Deimos, Amalthea..)

thanks much!

That looks like the same warnings I was getting. I just passed the

Code: Select all

CXXFLAGS=-fno-strict-aliasing

to ./configure

When I tried Boux's method I ran into my limit of knowledge. I don't know all the flags to put in. I got a configure error that gcc could not open the output file. I was also having other problems so I gave up. The ASCII mode files work without doing anything.

cartrite

[chris]

i get build errors without thease changes

Oops. Thanks for pointing these out. I just checked the changes into CVS.

--Chris

[steve]

A Fedora developer seems to have found the real fix for this problem.

Code: Select all

--- celestia-1.4.1/src/celengine/modelfile.cpp.strictalias   2006-11-22 14:04:15.000000000 +0100
+++ celestia-1.4.1/src/celengine/modelfile.cpp   2006-11-22 14:01:27.000000000 +0100
@@ -1080,7 +1080,9 @@
 static float readFloat(istream& in)
 {
     int i = readUint(in);
-    return *((float*) &i);
+    float f;
+    memcpy(&f, &i, sizeof(float));
+    return f;
 }


I've only tested this briefly, but it does seem to fix the problem.

There is more information in the bugzilla ticket, if anyone is interested:
https://bugzilla.redhat.com/bugzilla/sh ... ?id=203525

[John Van Vliet]

i will go and give it a try over the holiday