Celestia Forums

Hi.

I tried to compile the gtk2 version of celetia 1.3.2 with gcc 3.4.1. If fails with the following messages:

g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I.. -Wnon-virtual-dtor -Wno-long-long -W
undef -Wall -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -ansi -D_XOP
EN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -DNDEBUG -DNO_DEBUG -O2 -O
2 -fomit-frame-pointer -pipe -fno-exceptions -fno-check-new -O2 -Wall -ffast-ma
th -fexpensive-optimizations -fomit-frame-pointer -I/usr/include/gtk-2.0 -I/usr/
lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/p
ango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/in
clude -I/usr/include/gtkglext-1.0 -I/usr/lib/gtkglext-1.0/include -c -o bound
aries.o `test -f 'boundaries.cpp' || echo './'`boundaries.cpp
cc1plus: warning: command line option "-Wmissing-prototypes" is valid for C/ObjC
but not for C++
../celutil/resmanager.h: In member function `typename T::ResourceType* ResourceM
anager<T>::find(ResourceHandle) [with T = ModelInfo]':
body.cpp:575: instantiated from here
../celutil/resmanager.h:108: error: dependent-name `std::map<std::string, typena
me T::ResourceType*, std::less<std::string>, std::allocator<std::pair<const std:
:string, typename T::ResourceType*> > >::value_type' is parsed as a non-type, bu
t instantiation yields a type
../celutil/resmanager.h:108: note: say `typename std::map<std::string, typename
T::ResourceType*, std::less<std::string>, std::allocator<std::pair<const std::st
ring, typename T::ResourceType*> > >::value_type' if a type is meant
make[3]: *** [body.o] Error 1

Any ideas?

Thanks,
Jens

Sorry Jens, I can't help very much...

The problem is not gtk or kde, but the 3.4 series of gcc. GCC 3.3.3 works fine for me. But 3.4 claims to be MUCH MORE closer to the standard.
Unfortunately this also implies to flag errors for input that was accepted by pre 3.4-gcc's.

To quote the gcc release notice:

It is very likely that existing C++ code will need to be fixed.

For a multi-os project like celestia, it MAY be quite difficult to fix this without braking compilation by other compilers or introducing
ugly compiler-specific code.

Another quote from the release notice:

...this might be surprising at first sight, especially since most popular compilers do not correctly implement this rule.

and in some (rare) cases 3.4 generates different (but "correct") code compared to previous versions and other "popular" compilers.
Hmm...

Somebody with a 3.4 series GCC might be able to help. MAYBE it's not as bad as described above!

MfG - HJW

Jens wrote:Hi.

I tried to compile the gtk2 version of celetia 1.3.2 with gcc 3.4.1. If fails with the following messages:

g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I.. -Wnon-virtual-dtor -Wno-long-long -W
undef -Wall -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -ansi -D_XOP
EN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -DNDEBUG -DNO_DEBUG -O2 -O
2 -fomit-frame-pointer -pipe -fno-exceptions -fno-check-new -O2 -Wall -ffast-ma
th -fexpensive-optimizations -fomit-frame-pointer -I/usr/include/gtk-2.0 -I/usr/
lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/p
ango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/in
clude -I/usr/include/gtkglext-1.0 -I/usr/lib/gtkglext-1.0/include -c -o bound
aries.o `test -f 'boundaries.cpp' || echo './'`boundaries.cpp
cc1plus: warning: command line option "-Wmissing-prototypes" is valid for C/ObjC
but not for C++
../celutil/resmanager.h: In member function `typename T::ResourceType* ResourceM
anager<T>::find(ResourceHandle) [with T = ModelInfo]':
body.cpp:575: instantiated from here
../celutil/resmanager.h:108: error: dependent-name `std::map<std::string, typena
me T::ResourceType*, std::less<std::string>, std::allocator<std::pair<const std:
:string, typename T::ResourceType*> > >::value_type' is parsed as a non-type, bu
t instantiation yields a type
../celutil/resmanager.h:108: note: say `typename std::map<std::string, typename
T::ResourceType*, std::less<std::string>, std::allocator<std::pair<const std::st
ring, typename T::ResourceType*> > >::value_type' if a type is meant
make[3]: *** [body.o] Error 1

Any ideas?

Thanks,
Jens

Oh, an easy one, in src/celutil/resmanager.h "just" add the keyword 'typename' in line 108 :
loadedResources.insert(typename NameMap::value_type(resources[h].resolvedName, resources[h].resource));

And you need to do the same at line 75 :
handles.insert(typename ResourceHandleMap::value_type(info, h));

Now on my side it stop a little after (using KDE gui) screaming about conversion between QString and std::string...

I've just installed back gcc 3.3.4 to see what happen

with the patch found here http://www.celestiaproject.net/forum/viewtopic.php?t=5666 to solve my QString/std::string problem and the typename stuff I wrote above Celestia 1.3.2 has compiled cleanly with gcc 3.4.1 on my Slackware-current

The gcc 3.4 problem is SOLVED

I've made a formal patch here : http://cycojesus.free.fr/files/celestia ... -3.4.patch

It only include the 2 typename and NOT the qt-sdl patch.

The patch works

Thanks,
Jens

I had to make a slightly different patch so that the file would also build on Visual C++ 7.0. VC7 seems to like typename keywords only in type definitions and not expressions. Could someone with g++ 3.4 try out the change to resmanager.h that I just checked into CVS?

--Chris

chris wrote:I had to make a slightly different patch so that the file would also build on Visual C++ 7.0. VC7 seems to like typename keywords only in type definitions and not expressions. Could someone with g++ 3.4 try out the change to resmanager.h that I just checked into CVS?

--Chris

I give it a try...

...compiles OK and it works

It's me uphere

Anonymous wrote:

chris wrote:I had to make a slightly different patch so that the file would also build on Visual C++ 7.0. VC7 seems to like typename keywords only in type definitions and not expressions. Could someone with g++ 3.4 try out the change to resmanager.h that I just checked into CVS?

--Chris

I give it a try...

...compiles OK and it works

Excellent! Thank you for testing it for me.

--Chris