Compilation problem on Fedora Core 4

Report bugs, bug fixes and workarounds here.
Topic author
jeszy
Posts: 2
Joined: 04.07.2005
With us: 19 years 4 months

Compilation problem on Fedora Core 4

Post #1by jeszy » 04.07.2005, 09:36

Hello,

Celestia 1.3.2 does not compile on Fedora Core 4. My compiler is gcc 4.0:

Code: Select all

gcc --version
gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compilation stops with the following error:

Code: Select all

g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I..    -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -DNDEBUG -DNO_DEBUG -O2 -fno-exceptions -fno-check-new  -O2 -Wall -ffast-math -fexpensive-optimizations -fomit-frame-pointer  -c -o body.o `test -f 'body.cpp' || echo './'`body.cpp
cc1plus: warning: command line option "-Wmissing-prototypes" is valid for Ada/C/ObjC but not for C++
../celengine/model.h:67: warning: 'class Model::MeshComparator' has virtual functions but non-virtual destructor
../celengine/model.h:85: warning: 'class Model::OpacityComparator' has virtual functions but non-virtual destructor
../celengine/orbit.h:19: warning: 'class Orbit' has virtual functions but non-virtual destructor
../celengine/orbit.h:35: warning: 'class EllipticalOrbit' has virtual functions but non-virtual destructor
../celengine/orbit.h:62: warning: 'class OrbitSampleProc' has virtual functions but non-virtual destructor
../celengine/orbit.h:77: warning: 'class CachingOrbit' has virtual functions but non-virtual destructor
../celutil/resmanager.h: In member function 'typename T::ResourceType* ResourceManager<T>::find(ResourceHandle) [with T = ModelInfo]':
body.cpp:575:   instantiated from here
../celutil/resmanager.h:108: error: dependent-name 'std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,typename T::ResourceType*,std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >,std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, typename T::ResourceType*> > >::value_type' is parsed as a non-type, but instantiation yields a type
../celutil/resmanager.h:108: note: say 'typename std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,typename T::ResourceType*,std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >,std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, typename T::ResourceType*> > >::value_type' if a type is meant
make[3]: *** [body.o] Error 1


Best regards,

Peter

Nova
Posts: 1
Joined: 14.07.2005
With us: 19 years 4 months

Post #2by Nova » 14.07.2005, 21:42

I think it is because of the gcc compiler.
But you can use the celestia rpm which is in the extras on http://fedoraproject.org/extras/4/i386/repodata/
or you can write (as root) this in the terminal: yum install celestia
I had to restart my computer after this to run celestia.

Spaceman Spiff
Posts: 420
Joined: 21.02.2002
With us: 22 years 9 months
Location: Darmstadt, Germany.

Post #3by Spaceman Spiff » 15.07.2005, 23:04

...or go to gcc 4.0.1, or roll back to gcc 3.4.4 (http://gcc.gnu.org/). I'd guess people must have succeeded in compiling Cel 1.3.2 with GCC 3.4.4 or such due to contemporaneity.

I'm not an expert, but maybe GCC 4.0.0 possibly had 'issues'.

Spiff.

Avatar
John Van Vliet
Posts: 2944
Joined: 28.08.2002
With us: 22 years 2 months

re

Post #4by John Van Vliet » 16.08.2005, 07:43

i just installed fedora 4 and did a build from cvs . The build went mostly fine
there was an error pointing to a kde ap [ arts ] ( i am on gnome ) but after i commented out the macro check in configure the build went fine

so look into using cvs

LarryN
Posts: 2
Joined: 19.08.2005
With us: 19 years 3 months
Location: Poland

Post #5by LarryN » 19.08.2005, 18:13

I've got the same problem with CRUX.

Code: Select all

Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --prefix=/usr --libexecdir=/usr/lib --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-shared --disable-nls
Thread model: posix
gcc version 3.4.4 (CRUX)


Celestia build with glut suport.
libglut.so.3.7.1

pt
Posts: 1
Joined: 22.08.2005
With us: 19 years 3 months

Post #6by pt » 22.08.2005, 22:16

I managed to solve the problem by simply doing as the compiler suggests - I just added a typename to celutil/resmanager.h into the two lines mentioned in the error message (or one line: if you fix just that, you'll get another error message; simpler is to fix both places at once). So:

Code: Select all

handles.insert(typename ResourceHandleMap::value_type(info, h));

instead of:

Code: Select all

handles.insert(ResourceHandleMap::value_type(info, h));

and:

Code: Select all

loadedResources.insert(typename NameMap::value_type(resources[h].resolvedName, resources[h].resource));

instead of:

Code: Select all

loadedResources.insert(NameMap::value_type(resources[h].resolvedName, resources[h].resource));

That did the trick.


Return to “Bugs”