Page 1 of 2
GCC-4.0.x Issues Internal Cmod conversion problem solved?
Posted: 25.05.2006, 17:17
by 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
Re: Internal Cmod conversion riddle???????
Posted: 25.05.2006, 17:26
by chris
cartrite wrote: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
Posted: 25.05.2006, 17:38
by chris
I'm fairly certain I know exactly where the problem is . . . I'll check in the very simple fix later today.
--Chris
Posted: 25.05.2006, 17:57
by cartrite
Thanks Chris, I wouldn't know were to start.
cartrite
Posted: 26.05.2006, 07:03
by 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
Posted: 26.05.2006, 08:50
by 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 > returnI 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
Posted: 27.05.2006, 10:41
by cartrite
I ??Think?? I found a workaround. If you pass the option
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
Posted: 27.05.2006, 10:45
by t00fri
cartrite wrote:I ??Think?? I found a workaround. If you pass the option
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#knownIt'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
Posted: 27.05.2006, 10:49
by 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
Posted: 27.05.2006, 17:12
by 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
Posted: 19.06.2006, 19:22
by Boux
cartrite wrote:I ??Think?? I found a workaround. If you pass the option
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#knownIt'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:
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.+.+.
Posted: 20.06.2006, 06:22
by 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
Posted: 21.06.2006, 09:31
by 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
re
Posted: 04.07.2006, 04:10
by 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 rulesi will go and give the work around a try as soon as i log-off
my OS is Fedora5 32bit
Posted: 04.07.2006, 04:26
by cartrite
That looks like the same warnings I was getting. I just passed the
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
re
Posted: 04.07.2006, 05:18
by 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
Posted: 10.07.2006, 03:24
by 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!
cartrite wrote:That looks like the same warnings I was getting. I just passed the
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
Re: re
Posted: 10.07.2006, 05:53
by chris
john Van Vliet wrote:i get build errors without thease changes
Oops. Thanks for pointing these out. I just checked the changes into CVS.
--Chris
Posted: 22.11.2006, 20:53
by 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
re
Posted: 23.11.2006, 05:32
by John Van Vliet
i will go and give it a try over the holiday