Page 1 of 1

GCC 4.7.x needs '-fpermissive' in CXXFLAGS? (0.5.1-r1)

Posted: Tue Oct 30, 2012 10:41 pm
by ermo
Just getting started with VS and trying to compile per the instructions, I get this error (config.log attached) on XUbuntu 12.10 x64:

Code: Select all

depbase=`echo src/gfx/quadsquare.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
	g++ -DHAVE_CONFIG_H -I.   -DBOOST_PYTHON_NO_PY_SIGNATURES -DBOOST_PYTHON_STATIC_LIB -I./boost/1_45    -DHAVE_SDL=1 -DSDL_WINDOWING=1      -DHAVE_AL=1   -DHAVE_OGG  -DNV_CUBE_MAP=1 -DDATA_DIR=\"/home/ermo/VegaStrike/0.5.1-r1/data\"  -I/usr/include/python2.7 -DHAVE_PYTHON=1    -I./src   -pipe -DNV_CUBE_MAP -O2 -ffast-math  -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -pthread -MT src/gfx/quadsquare.o -MD -MP -MF $depbase.Tpo -c -o src/gfx/quadsquare.o src/gfx/quadsquare.cpp &&\
	mv -f $depbase.Tpo $depbase.Po
In file included from src/gfx/quadsquare.h:18:0,
                 from src/gfx/quadsquare.cpp:16:
./src/resizable.h: In instantiation of ‘Resizable<ITEM>::Resizable(const Resizable<ITEM>&) [with ITEM = unsigned int]’:
src/gfx/quadsquare.h:71:8:   required from ‘void std::vector<_Tp, _Alloc>::_M_insert_aux(std::vector<_Tp, _Alloc>::iterator, const _Tp&) [with _Tp = TextureIndex; _Alloc = std::allocator<TextureIndex>; std::vector<_Tp, _Alloc>::iterator = __gnu_cxx::__normal_iterator<TextureIndex*, std::vector<TextureIndex> >; typename std::_Vector_base<_Tp, _Alloc>::pointer = TextureIndex*]’
/usr/include/c++/4.7/bits/stl_vector.h:893:4:   required from ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = TextureIndex; _Alloc = std::allocator<TextureIndex>; std::vector<_Tp, _Alloc>::value_type = TextureIndex]’
src/gfx/quadsquare.cpp:351:47:   required from here
./src/resizable.h:19:9: error: ‘memcpy’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
In file included from /usr/include/string.h:642:0,
                 from ./src/pk3.h:42,
                 from ./src/vsfilesystem.h:13,
                 from src/gfx/vsimage.h:4,
                 from src/gfx/aux_texture.h:23,
                 from src/gfx/quadsquare.cpp:18:
/usr/include/x86_64-linux-gnu/bits/string3.h:49:1: note: ‘void* memcpy(void*, const void*, size_t)’ declared here, later in the translation unit
make[1]: *** [src/gfx/quadsquare.o] Error 1
make[1]: Leaving directory `/home/ermo/VegaStrike/0.5.1-r1/vegastrike'
make: *** [all] Error 2
Any tips/pointers much appreciated. :)

EDIT: Adding '-fpermissive' to CXXFLAGS per the error message (and after reading this Arch Linux packaging discussion) seems to have solved the issue.

EDIT2: "make -j2" works fine. Neat. It takes 7m30s to build on my old-ish C2D Pentium E5700 3GHz box w/-j2 on a slow disk with cold cache.

EDIT3: On the odd chance that someone else sees this, it turns out that ./configure actually has an option that adds -fpermissive to CXXFLAGS in the generated Makefile. It's simply a question of adding the argument "--enable-permissive" to ./configure (see "./configure --help" for more interesting options)

Re: GCC 4.7.x needs '-fpermissive' in CXXFLAGS? (XUbuntu 12.

Posted: Tue Oct 30, 2012 11:33 pm
by klauss
I think more than -fpermissive, resizable.h should include memory.h, which is where memcpy is defined if memory serves correctly (NPI)

Re: GCC 4.7.x needs '-fpermissive' in CXXFLAGS? (XUbuntu 12.

Posted: Wed Oct 31, 2012 12:06 am
by ermo
klauss wrote:I think more than -fpermissive, resizable.h should include memory.h, which is where memcpy is defined if memory serves correctly (NPI)
Good call 8) -- this fixed it on my system when compiling the 0.5.1-r1 tagged version.

from running "svn diff":

Code: Select all

Index: src/resizable.h
===================================================================
--- src/resizable.h	(revision 13429)
+++ src/resizable.h	(working copy)
@@ -1,4 +1,5 @@
 #include <cstdlib>
+#include <memory.h>
 template < class ITEM >
 class Resizable
 {
However (!) disabling -fpermissive made more scope issues crop up. Do you want me to keep reporting for the tagged version, or would it be more productive for me to report any issues I encounter against trunk?

This is what it gave me:

Code: Select all

In file included from src/cmd/unit.cpp:56:0:
src/cmd/unit_jump.h: In instantiation of ‘bool GameUnit<UnitType>::TransferUnitToSystem(unsigned int, StarSystem*&, bool) [with UnitType = Asteroid]’:
src/cmd/unit.cpp:726:16:   required from here
src/cmd/unit_jump.h:111:29: error: ‘SetCurPosition’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
src/cmd/unit_jump.h:111:29: note: declarations in dependent base ‘Unit’ are not found by unqualified lookup
src/cmd/unit_jump.h:111:29: note: use ‘this->SetCurPosition’ instead
src/cmd/unit_jump.h: In instantiation of ‘bool GameUnit<UnitType>::TransferUnitToSystem(unsigned int, StarSystem*&, bool) [with UnitType = Building]’:
src/cmd/unit.cpp:729:16:   required from here
src/cmd/unit_jump.h:111:29: error: ‘SetCurPosition’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
src/cmd/unit_jump.h:111:29: note: declarations in dependent base ‘Unit’ are not found by unqualified lookup
src/cmd/unit_jump.h:111:29: note: use ‘this->SetCurPosition’ instead
src/cmd/unit_jump.h: In instantiation of ‘bool GameUnit<UnitType>::TransferUnitToSystem(unsigned int, StarSystem*&, bool) [with UnitType = Planet]’:
src/cmd/unit.cpp:732:16:   required from here
src/cmd/unit_jump.h:111:29: error: ‘SetCurPosition’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
src/cmd/unit_jump.h:111:29: note: declarations in dependent base ‘Unit’ are not found by unqualified lookup
src/cmd/unit_jump.h:111:29: note: use ‘this->SetCurPosition’ instead
src/cmd/unit_jump.h: In instantiation of ‘bool GameUnit<UnitType>::TransferUnitToSystem(unsigned int, StarSystem*&, bool) [with UnitType = Unit]’:
src/cmd/unit.cpp:735:16:   required from here
src/cmd/unit_jump.h:111:29: error: ‘SetCurPosition’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
src/cmd/unit_jump.h:111:29: note: declarations in dependent base ‘Unit’ are not found by unqualified lookup
src/cmd/unit_jump.h:111:29: note: use ‘this->SetCurPosition’ instead
depbase=`echo src/gldrv/gl_init.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
	g++ -DHAVE_CONFIG_H -I.   -DBOOST_PYTHON_NO_PY_SIGNATURES -DBOOST_PYTHON_STATIC_LIB -I./boost/1_45    -DHAVE_SDL=1 -DSDL_WINDOWING=1      -DHAVE_AL=1   -DHAVE_OGG  -DNV_CUBE_MAP=1 -DDATA_DIR=\"/home/ermo/VegaStrike/0.5.1-r1/data\"  -I/usr/include/python2.7 -DHAVE_PYTHON=1    -I./src   -pipe -DNV_CUBE_MAP -O2 -ffast-math -msse2 -msse3 -mssse3  -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -pthread -MT src/gldrv/gl_init.o -MD -MP -MF $depbase.Tpo -c -o src/gldrv/gl_init.o src/gldrv/gl_init.cpp &&\
	mv -f $depbase.Tpo $depbase.Po
src/cmd/unit_jump.h: In instantiation of ‘bool GameUnit<UnitType>::TransferUnitToSystem(unsigned int, StarSystem*&, bool) [with UnitType = Missile]’:
src/cmd/unit.cpp:738:16:   required from here
src/cmd/unit_jump.h:111:29: error: ‘SetCurPosition’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
src/cmd/unit_jump.h:111:29: note: declarations in dependent base ‘Unit’ are not found by unqualified lookup
src/cmd/unit_jump.h:111:29: note: use ‘this->SetCurPosition’ instead
src/cmd/unit_jump.h: In instantiation of ‘bool GameUnit<UnitType>::TransferUnitToSystem(unsigned int, StarSystem*&, bool) [with UnitType = Nebula]’:
src/cmd/unit.cpp:741:16:   required from here
src/cmd/unit_jump.h:111:29: error: ‘SetCurPosition’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
src/cmd/unit_jump.h:111:29: note: declarations in dependent base ‘Unit’ are not found by unqualified lookup
src/cmd/unit_jump.h:111:29: note: use ‘this->SetCurPosition’ instead
src/cmd/unit_jump.h: In instantiation of ‘bool GameUnit<UnitType>::TransferUnitToSystem(unsigned int, StarSystem*&, bool) [with UnitType = Enhancement]’:
src/cmd/unit.cpp:744:16:   required from here
src/cmd/unit_jump.h:111:29: error: ‘SetCurPosition’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
src/cmd/unit_jump.h:111:29: note: declarations in dependent base ‘Unit’ are not found by unqualified lookup
src/cmd/unit_jump.h:111:29: note: use ‘this->SetCurPosition’ instead
make[1]: *** [src/cmd/unit.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/home/ermo/VegaStrike/0.5.1-r1/vegastrike'
make: *** [all] Error 2
The reason I use the tagged version right now is that I wanted to get started with a known working version when digging into the PU porting work. But if I want the recent AI patch(es), your comment in the "Wake up Call!" thread seems to suggest that I would need a post-0.5.1-r1 version?

EDIT: Oh, and while we're at it: I noticed that you guys are considering moving away from SourceForge. As I noticed that you, klauss, expressed a preference for mercurial, I would recommend taking a look at bitbucket, which hosts both mercurial and git repos and which is owned by Atlassian and so isn't likely to go out of business any time soon. Begin able to do pull requests might be a boon, even if switching the code base over to a DVCS might entail some initial growing pains...

Re: GCC 4.7.x needs '-fpermissive' in CXXFLAGS? (XUbuntu 12.

Posted: Wed Oct 31, 2012 2:38 am
by klauss
ermo wrote: However (!) disabling -fpermissive made more scope issues crop up. Do you want me to keep reporting for the tagged version, or would it be more productive for me to report any issues I encounter against trunk?
Trunk builds against gcc 4.7 :-p

Re: GCC 4.7.x needs '-fpermissive' in CXXFLAGS? (XUbuntu 12.

Posted: Wed Oct 31, 2012 2:43 am
by klauss
ermo wrote:EDIT: Oh, and while we're at it: I noticed that you guys are considering moving away from SourceForge. As I noticed that you, klauss, expressed a preference for mercurial, I would recommend taking a look at bitbucket, which hosts both mercurial and git repos and which is owned by Atlassian and so isn't likely to go out of business any time soon. Begin able to do pull requests might be a boon, even if switching the code base over to a DVCS might entail some initial growing pains...
No, I will shoot down any attempts at moving away from SF.

First, if moving towards a different VCS is the motive, git isn't really my friend, and mercurial (which it is) can't handle large binary blobs gracefully. I've had experience with that. Maybe in a year or two I'll check again.

Second, we have a really, really HUGE source tree. Add file releases for older versions, and it's HUGER. Think tens of gigs. SF has been really good to us, we've exceeded their soft quota many-fold for years, and they're still hosting us. I'm not sure other free hosting services would be as friendly. Not to mention the hassle migrating with history would be. (without history would be unacceptable)

Re: GCC 4.7.x needs '-fpermissive' in CXXFLAGS? (XUbuntu 12.

Posted: Wed Oct 31, 2012 12:25 pm
by ermo
klauss wrote:
ermo wrote: However (!) disabling -fpermissive made more scope issues crop up. Do you want me to keep reporting for the tagged version, or would it be more productive for me to report any issues I encounter against trunk?
Trunk builds against gcc 4.7 :-p
Hehe, point taken. ;)

Which sort of process do you go through when cutting new point releases? And by point releases, I mean -r1,-r2,-r3 etc. which don't necessarily change any mechanics or game assets but are just technical fixes?

Am I correct in assuming that everything is cut directly from trunk via tags? In your opinion, is it worth it to backport the compilation fixes to e.g. 0.5.1-r2 or would you rather do, say, a 0.5.2 which includes e.g. the fixed AI?

Just curious -- not meaning to sound pushy or anything. :mrgreen:

Re: GCC 4.7.x needs '-fpermissive' in CXXFLAGS? (0.5.1-r1)

Posted: Wed Oct 31, 2012 1:28 pm
by klauss
The compatibility fixes aren't enough to warrant a new release, albeit note that they have been applied primarily because packaging for newer distributions required them (so many r1s out there already have them applied as downstream patches).

r2 would have to be due to some important fix. Imagine, for instance, we fix the crashes for AMD GPUs. That would merit an r2. :)

Short of that, I'd push towards 0.5.2 (not that big a leap if you check the roadmap)