Compiling spring (mingw and visual studio 7/8)

Tobi · Post by **Tobi** » 28 Jun 2006, 16:44

wasn't that fixed already by your patch AF? or is this the other VS version?

AF · Post by AF » 28 Jun 2006, 16:46

That was fixed in the final release mode of the VS7 project.

the other 2 modes, and the 3 modes in the VS8 build still have the issue.

Opening the VSProjects in a texteditor and searching for SDL-1.2.8 and replacing the 8 with a 9 should fix it.

smoth · Post by **smoth** » 28 Jun 2006, 18:55

Sean Mirrsen wrote:Perhaps the fact you have to extract vclibs to a "vclibs" folder just like I forgot to?

Nah, got that..

AF wrote:Opening the VSProjects in a texteditor and searching for SDL-1.2.8 and replacing the 8 with a 9 should fix it.

I opened it in a text editor but did not find the refference.. are you talking about the .vcproj or another file?

*edit* I did not find it because the file already has .9 in it.

So, um what else could I have fucked up?

AF · Post by AF » 28 Jun 2006, 19:08

there should be 6 references not 1, 2 for each mode, debug, release, and final releae.

Check them in VS too in project settings, additional include directories and additional library directories.

smoth · Post by **smoth** » 28 Jun 2006, 20:18

Compiled, but I have these warnnings... do I need to worry?

LINK : warning LNK4098: defaultlib 'LIBC' conflicts with use of other libs; use /NODEFAULTLIB:library
FBO.obj : warning LNK4217: locally defined symbol ___glewDeleteFramebuffersEXT imported in function "public: virtual __thiscall FBO::~FBO(void)" (??1FBO@@UAE@XZ)
FBO.obj : warning LNK4217: locally defined symbol ___glewBindFramebufferEXT imported in function "public: virtual __thiscall FBO::~FBO(void)" (??1FBO@@UAE@XZ)
FBO.obj : warning LNK4217: locally defined symbol ___glewCheckFramebufferStatusEXT imported in function "public: virtual void __thiscall FBO::checkFBOStatus(void)" (?checkFBOStatus@FBO@@UAEXXZ)
FBO.obj : warning LNK4217: locally defined symbol ___glewFramebufferTexture2DEXT imported in function "public: virtual void __thiscall FBO::attachTexture(unsigned int,unsigned int,enum FramebufferAttachType)" (?attachTexture@FBO@@UAEXIIW4FramebufferAttachType@@@Z)
FBO.obj : warning LNK4217: locally defined symbol ___glewGenFramebuffersEXT imported in function "public: __thiscall FBO::FBO(void)" (??0FBO@@QAE@XZ)
FBO.obj : warning LNK4217: locally defined symbol ___GLEW_EXT_framebuffer_object imported in function "public: __thiscall FBO::FBO(void)" (??0FBO@@QAE@XZ)
WinPBuffer.obj : warning LNK4217: locally defined symbol ___wglewDestroyPbufferARB imported in function "public: virtual __thiscall WinPBuffer::~WinPBuffer(void)" (??1WinPBuffer@@UAE@XZ)
WinPBuffer.obj : warning LNK4217: locally defined symbol ___wglewReleasePbufferDCARB imported in function "public: virtual __thiscall WinPBuffer::~WinPBuffer(void)" (??1WinPBuffer@@UAE@XZ)
WinPBuffer.obj : warning LNK4217: locally defined symbol ___wglewReleaseTexImageARB imported in function "public: virtual void __thiscall WinPBuffer::select(void)" (?select@WinPBuffer@@UAEXXZ)
WinPBuffer.obj : warning LNK4217: locally defined symbol ___wglewBindTexImageARB imported in function "public: virtual void __thiscall WinPBuffer::deselect(void)" (?deselect@WinPBuffer@@UAEXXZ)
WinPBuffer.obj : warning LNK4217: locally defined symbol ___wglewGetPbufferDCARB imported in function "public: __thiscall WinPBuffer::WinPBuffer(int)" (??0WinPBuffer@@QAE@H@Z)
WinPBuffer.obj : warning LNK4217: locally defined symbol ___wglewCreatePbufferARB imported in function "public: __thiscall WinPBuffer::WinPBuffer(int)" (??0WinPBuffer@@QAE@H@Z)
WinPBuffer.obj : warning LNK4217: locally defined symbol ___WGLEW_NV_render_depth_texture imported in function "public: __thiscall WinPBuffer::WinPBuffer(int)" (??0WinPBuffer@@QAE@H@Z)

Tobi · Post by **Tobi** » 28 Jun 2006, 22:03

No need to worry I think, MinGW spews out those errors too on linking here and everything seemed to work fine...

Post by **ILMTitan** » 29 Jun 2006, 05:08

As of revision 1544 I get 6 compile errors in VC03, plus 6 of new warnings complaining about inconsistent dll linkage in the AI interface class destructors.

Code: Select all

rts error LNK2019: unresolved external symbol "__declspec(dllimport) const IAICallback::`vftable'" (__imp_??_7IAICallback@@6B@) referenced in function "public: virtual __thiscall IAICallback::~IAICallback(void)" (??1IAICallback@@UAE@XZ)

rts error LNK2019: unresolved external symbol "__declspec(dllimport) const IAICheats::`vftable'" (__imp_??_7IAICheats@@6B@) referenced in function "public: virtual __thiscall IAICheats::~IAICheats(void)" (??1IAICheats@@UAE@XZ)

rts error LNK2019: unresolved external symbol "__declspec(dllimport) const IGlobalAI::`vftable'" (__imp_??_7IGlobalAI@@6B@) referenced in function "public: virtual __thiscall IGlobalAI::~IGlobalAI(void)" (??1IGlobalAI@@UAE@XZ)

rts error LNK2019: unresolved external symbol "__declspec(dllimport) const IGlobalAICallback::`vftable'" (__imp_??_7IGlobalAICallback@@6B@) referenced in function "public: virtual __thiscall IGlobalAICallback::~IGlobalAICallback(void)" (??1IGlobalAICallback@@UAE@XZ)

rts error LNK2019: unresolved external symbol "__declspec(dllimport) const IGroupAI::`vftable'" (__imp_??_7IGroupAI@@6B@) referenced in function "public: virtual __thiscall IGroupAI::~IGroupAI(void)" (??1IGroupAI@@UAE@XZ)

rts error LNK2019: unresolved external symbol "__declspec(dllimport) const IGroupAICallback::`vftable'" (__imp_??_7IGroupAICallback@@6B@) referenced in function "public: virtual __thiscall IGroupAICallback::~IGroupAICallback(void)" (??1IGroupAICallback@@UAE@XZ)

Tobi · Post by **Tobi** » 29 Jun 2006, 09:53

Add BUILDING_SPRING to preprocessor #defines in build options. It's needed to fix up vtables and AIs and stuff.

Post by **ILMTitan** » 30 Jun 2006, 02:39

That took care of the warnings, but not the errors.

Post by **jcnossen** » 30 Jun 2006, 15:15

I seriously think this whole vtable issue needs to be solved on GCC/scons only. There are no problems on VStudio with vtables anyway.
(Why should vs need extra defines when gcc messes it up?)

Jonny C · Post by **Jonny C** » 30 Jun 2006, 20:32

Hi, I've tried compling the source under VS2005 and i get an error about resources.h being missing

It's not there :p

heres the error:

Code: Select all

Compiling resources...
.\rts.rc(3) : fatal error RC1015: cannot open include file 'resource.h'.
Build log was saved at "file://c:\taspring_0.72b1\rts\build\vstudio7\Release\BuildLog.htm"
rts - 1 error(s), 17 warning(s)

if i do a search for "resources" in the source folder, i only get...
\game\gamedata\resources.tdf
\AI\Global\NTAI\resources\
\AI\Global\JCAI\profiles\xta_core_resources.cfg

patmo98 · Post by **patmo98** » 30 Jun 2006, 20:55

Jonny C wrote:Hi, I've tried compling the source under VS2005 and i get an error about resources.h being missing

It's not there :p

heres the error:
Code: Select all
Compiling resources...
.\rts.rc(3) : fatal error RC1015: cannot open include file 'resource.h'.
Build log was saved at "file://c:\taspring_0.72b1\rts\build\vstudio7\Release\BuildLog.htm"
rts - 1 error(s), 17 warning(s)

You should be looking for resource.h not resources.h
I would try replacing the path with ../vstudio8/resource.h

I won't have access to internet until Monday. Good luck.

Jonny C · Post by **Jonny C** » 30 Jun 2006, 21:02

t h a n k y o u ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

Sean Mirrsen · Post by **Sean Mirrsen** » 01 Jul 2006, 19:47

I get linker errors with current SVN code, with IAICallback, IAICheats, IGroupAICallback, and IGlobalAICallback seeming to have missing virtual destructors - whatever the "DECLARE_PURE_VIRTUAL" is supposed to be, it doesn't work.

Tobi · Post by **Tobi** » 01 Jul 2006, 20:01

which revision? (to make sure you tried the last one)

Sean Mirrsen · Post by **Sean Mirrsen** » 01 Jul 2006, 20:04

Just updated, and tried to compile. Should be the latest. Does number 1558 mean anything?

Tobi · Post by **Tobi** » 01 Jul 2006, 20:24

yes, thats latest.

Guess MSVC doesn't support (pure) virtual destructors across DLL boundaries at all...

I'll just disable them and reintroduce all potential bugs related to them on MSVC (and MinGW as I couldn't get it to link destructors...). Disabling it is easy now I got it all macrofied anyway.

So try again and it should work.

Sean Mirrsen · Post by **Sean Mirrsen** » 01 Jul 2006, 20:31

It might be just VC 2003 that doesn't support them, maybe 2005 does.

In any case, it compiled now, thanks.

AF · Post by AF » 01 Jul 2006, 21:42

I thought interface classes shouldnt have destructors, only the classes based on them

Tobi · Post by **Tobi** » 01 Jul 2006, 22:51

No.

If you don't give a class with any virtual methods no destructor, the compiler will generate a non-virtual empty default one.

This means that if you have an interface class 'Interface' and a pointer to an object which derives from Interface, deleting the pointer will NOT call the destructor of your derived class (possible memory leaks), ie.

Code: Select all

class Interface {
  virtual void foo();
}
class Object:public Interface {
  ~Object() { delete[] data; }
  unsigned char* data;
}
// in a function:
Interface* p = new Object;
delete p; // <-- memory leak ~Object is not called, so data is not deleted

I now (or since a while actually) realise spring was working around this by C style casting the pointer p back to Object*, and then deleting it (in AIs).

This happened to work, but it would silently break and crash hard in case you'd ever use multiple or virtual inheritance.

It'd also leak memory/crash in case you'd set up your AI in certain ways, like having a common CMyAI class (implementing the core of your AI) deriving from IGlobalAI and separate derivatives of CMyAI that specialize it for e.g. metal maps, water maps and normal maps, or different mods.

Spring RTS Engine

Compiling spring (mingw and visual studio 7/8)