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

Trying to build your own version of Vega Strike and having problems? Unix users, paste your config.log here (stderr output alone is not helpful).

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

Postby ermo » Tue Oct 30, 2012 3:41 pm

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)
Attachments
config.log.gz
config.log as requested (gzipped for a 10:1 reduction in size)
(14.3 KiB) Downloaded 125 times
Last edited by ermo on Thu Nov 01, 2012 1:03 pm, edited 3 times in total.
Privateer: Wing Commander Universe -- the continuation of chuck_starchaser's Privateer: Parallel Universe mod.
ermo
Mercenary
Mercenary
 
Posts: 104
Topics: 5
Joined: Tue Oct 30, 2012 12:46 pm

Share On:

Share on Facebook Facebook Share on Twitter Twitter Share on Digg Digg

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

Postby klauss » Tue Oct 30, 2012 4:33 pm

I think more than -fpermissive, resizable.h should include memory.h, which is where memcpy is defined if memory serves correctly (NPI)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

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

Postby ermo » Tue Oct 30, 2012 5:06 pm

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...
Privateer: Wing Commander Universe -- the continuation of chuck_starchaser's Privateer: Parallel Universe mod.
ermo
Mercenary
Mercenary
 
Posts: 104
Topics: 5
Joined: Tue Oct 30, 2012 12:46 pm

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

Postby klauss » Tue Oct 30, 2012 7:38 pm

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
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

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

Postby klauss » Tue Oct 30, 2012 7:43 pm

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)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

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

Postby ermo » Wed Oct 31, 2012 5:25 am

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:
Last edited by ermo on Wed Oct 31, 2012 6:32 am, edited 1 time in total.
Privateer: Wing Commander Universe -- the continuation of chuck_starchaser's Privateer: Parallel Universe mod.
ermo
Mercenary
Mercenary
 
Posts: 104
Topics: 5
Joined: Tue Oct 30, 2012 12:46 pm

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

Postby klauss » Wed Oct 31, 2012 6:28 am

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)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina



Return to Compiling Problems [paste config.log]

Who is online

Users browsing this forum: No registered users and 1 guest