Vega Strike Forums

Posted: **Fri Nov 23, 2012 4:22 am**

It looks like every year around November I have to make another attempt at compiling VS with mingw.

Last year's attempt http://forums.vega-strike.org/viewtopic.php?f=5&t=17719 wasn't overall very successful, and it eventually petered off without producing an actual executable. Can we do better this year?

Here's the setup.
1. Freshly installed Win7. No traces of old compilers or libraries left around.
2. installed mingw (mingw-get-inst-20120426), upgrading packages to all the most recent versions while installing. Se3lected to also install Msys along with the C and C++ compilers.
3. Installed Code::Blocks 10.05 with all plugins
4. Installed Cmake 2.8.10.1 (I don't intend to use it, but just in case)
5. checked out vegastrike and vega-vc9 as of revision 13449
6. imported vegastrike.sln from vega-vc9 into Code::Blocks (configured to use mingw as default compiler)
7. quick look at the project to make sure something obvious isn't wrong, all recent files are included, etc.
8. made vegastrike project active, and selected release/win32 configuration
9.build
10. ??
11. profit - ?! Not really.

Actually at 10 I get:

10. first error crops.

Code: Select all

C:\games\vegastrike\mingw-work\vegastrike\src\vsfilesystem.h|82|error: 'stdext' does not name a type|
C:\games\vegastrike\mingw-work\vegastrike\src\vsfilesystem.h|83|error: 'FileLookupCache' was not declared in this scope|
C:\games\vegastrike\mingw-work\vegastrike\src\vsfilesystem.h|83|error: 'cache' was not declared in this scope|
C:\games\vegastrike\mingw-work\vegastrike\src\vsfilesystem.h|83|error: expected primary-expression before 'const'|
C:\games\vegastrike\mingw-work\vegastrike\src\vsfilesystem.h|83|error: expected primary-expression before 'type'|
C:\games\vegastrike\mingw-work\vegastrike\src\vsfilesystem.h|83|error: expression list treated as compound expression in initializer [-fpermissive]|
C:\games\vegastrike\mingw-work\vegastrike\src\vsfilesystem.h|131|error: 'stdext' does not name a type|

The offending code in vsfilesystem.h is:

Code: Select all

typedef vsUMap< string, VSError > FileLookupCache;
VSError CachedFileLookup( FileLookupCache &cache, const string &file, VSFileType type );

(edit) I tried looking up on the board if this error was previously seen by someone else, but the board search function is weird. I get errors such as "The following words in your search query were ignored because they are too common words: filelookupcache" Really - filelookupcache is too common a word? So I came out empty handed.

(edit2) google to the rescue! It seems that actually I have hit the same problem before myself, at least twice.
http://forums.vega-strike.org/viewtopic.php?f=5&t=15265
http://forums.vega-strike.org/viewtopic ... 9&start=25

Let me refresh my memory and see if I can remember the fix.

(edit3) Hmm it seems that the current source does include the fix from last year when I came across this problem... Quote from src/gnuhash.h

Code: Select all

#ifdef _WIN32
#ifdef HAVE_TR1_UNORDERED_MAP
#if defined(_MSC_VER) && _MSC_VER >= 1600
#include <unordered_map>  //MSVC doesn't use tr1 dirs
#else
#include <tr1/unordered_map>
#endif

Which should work OK on mingw - at least it did 1 year ago. Dunno why it's broken again now.

(edit4) Even if I force the inclusion of tr1/unordered_map I still get the same error.

Posted: **Fri Nov 23, 2012 4:36 am**

No, you should just look at the first error. All the others are just gcc (and mingw is gcc) desperately and futilely trying to make sense of the source, in spite of that first error.

In this case, the underlying problem is in gnuhash.h's definition of vsUMap. I'd guess you have to define HAVE_TR1_UNORDERED_MAP

Posted: **Fri Nov 23, 2012 4:43 am**

Okay let me start over. I'll restore everything the way it was and add HAVE_TR1_UNORDERED_MAP as a preprocessor define, OK?

(edit) That worked. That brings us to:

10. Add HAVE_TR1_UNORDERED_MAP as a #define for the C++ preprocessor in the current project (vegastrike > properties > project's build options > compiler settings > #defines)

Posted: **Fri Nov 23, 2012 4:50 am**

Next, after #10 is taken care of.

11. ..\..\vegastrike\src\SharedPool.h|12|error: expected type-specifier|
src/SharedPool.h:

Code: Select all

template < class T, class RefcounterTraits = vsHashComp< T > >

Posted: **Fri Nov 23, 2012 6:16 am**

Check vsHashComp

Posted: **Fri Nov 23, 2012 8:03 am**

Yeah it's the same stuff that ground me to a halt last year. Still don't know what to do about it.

Posted: **Fri Nov 23, 2012 10:13 am**

I am able to compile with mingw. Getting platform related changes/patches accepted in vegastrike is... well, not so easy. But there is msvc, so it is ok I guess.

Add this placebo to the tr1 related section to fix the error:
namespace std { namespace tr1 { template <typename T> class hash_compare {}; } }

Posted: **Fri Nov 23, 2012 3:11 pm**

log0 wrote:Add this placebo to the tr1 related section to fix the error:
namespace std { namespace tr1 { template <typename T> class hash_compare {}; } }

I'm moderately sure that class has to have something inside.

Posted: **Fri Nov 23, 2012 4:09 pm**

log0 wrote: Add this placebo to the tr1 related section to fix the error:
namespace std { namespace tr1 { template <typename T> class hash_compare {}; } }

I still get the error even with the "placebo" added.

Posted: **Fri Nov 23, 2012 5:24 pm**

Patch:

Posted: **Fri Nov 23, 2012 8:22 pm**

11. Applied the patch from log0; this allows the compilation to continue past the error.

Stay tuned.

12. New error:

Code: Select all

C:\games\vegastrike\mingw-work\vegastrike\src\audio\codecs\OggStream.cpp|39|error: 'malloc' was not declared in this scope|

Source: src/audio/codecs/OggStream.cpp line 39

Code: Select all

        readBuffer = malloc(readBufferSize);

Posted: **Fri Nov 23, 2012 8:37 pm**

missing #include <stdlib.h>

That'd be a no-brainer patch (as in no need to review much, or ifdef for win, merge right in even for linux).

Posted: **Fri Nov 23, 2012 8:47 pm**

Well I have no brain to speak of.

So,

12. Add

Code: Select all

#include <stdlib.h>

to the top of OggStream.cpp

Posted: **Fri Nov 23, 2012 8:55 pm**

13.

Code: Select all

..\include\GL\glut.h|43|error: redeclaration of C++ built-in type 'wchar_t' [-fpermissive]|

Code: Select all

typedef unsigned short wchar_t;

Shouldn't this have been a warning instead?

Anyway, I added _WCHAR_T_DEFINED to project's #defines. Compilation continues.

Posted: **Fri Nov 23, 2012 9:44 pm**

Compile ended, linker complains about lvorbis_static, lvorbisfile_static, logg_static and lpng_static. Guess I'll have to compile all of those with mingw as well. Will do later today.

Posted: **Fri Nov 23, 2012 10:07 pm**

Hmm, you might also need SDL/SDLmain.

My defines list:
WIN32
_WIN32
_WINDOWS
NOMINMAX
HAVE_AL
HAVE_SDL
SDL_WINDOWING
HAVE_OGG
HAVE_BOOST
HAVE_PYTHON
HAVE_BOOLEAN
JPEG_SUPPORT
BOOST_PYTHON_NO_PY_SIGNATURES
BOOST_PYTHON_STATIC_LIB
BOOST_ALL_NO_LIB
NV_CUBE_MAP
YY_ALWAYS_INTERACTIVE
HAVE_TR1_UNORDERED_MAP
CLIENT

Posted: **Fri Nov 23, 2012 10:33 pm**

I think we might be able to remove YY_ALWAYS_INTERACTIVE as I think that is a holdover from the days when part of the engine used lex/yacc parsed code. Can you comment on that klauss?

Posted: **Fri Nov 23, 2012 11:03 pm**

Actually, we use yacc-generated code. I'm not sure whether we can get rid of that define (because of yacc-generated code).

Posted: **Sat Nov 24, 2012 12:11 am**

14. At linking stage, the included static libraries don't work. You need mingw-specific versions. In particular the linker complains about libpng, libvorbis, libogg and libvorbisfile.

a. install zlib in mingw: mingw-get install libz-dev
b. compile libpng and install; it goes by default in the msys directory which (I remembered later) is not searched my default by mingw; fixed by copying the includes and libs from /usr/local/ to / (I'm sure that there's a better way of doing it, but for my purposes should suffice)
c. compile ogg and install again in default directory, later moved to /
d. compile vorbis (on mingw/msys it can't find the previously installed ogg by default, so you have to specify ./configure --with-ogg=path-to-ogg); again move to / after install

(edit) the libraries versions I used are: libpng-1.5.13; libogg-1.3.0; libvorbis-1.3.3

There, that should satisfy the linker. Let's see if it asks for anything else.

Posted: **Sat Nov 24, 2012 12:22 am**

damn, I get the exact same linking errors, despite the libs being there. I guess it's about finding lpng_static as opposed to lpng, etc. Lemme see if I can fix it.

(edit)

14a. In project build properties> release-win32> linker options I renamed the libraries as such:
libvorbis_static to libvorbis
libvorbisfile_static to libvorbisfile
libogg_static to libogg
zlib_static to libz (argh! When is it zlib and when libz?)
libpng_static to libpng.

The previous linking errors don't show up anymore, yet this crops:

Code: Select all

||Warning: .drectve `/manifestdependency:"type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'" /DEFAULTLIB:"MSVCRT" /DEFAULTLIB:"OLDNAMES" ' unrecognized|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyInt_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyInt_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyLong_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyBool_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyFloat_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyString_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyUnicode_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyComplex_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp___Py_NoneStruct'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyComplex_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyFloat_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyFloat_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyFloat_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyFloat_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyComplex_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyFloat_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyComplex_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyFloat_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp___Py_NoneStruct'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp___Py_NoneStruct'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp___Py_NoneStruct'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyComplex_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyComplex_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyComplex_Type'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyExc_OverflowError'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyExc_OverflowError'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyExc_OverflowError'|
Release Win32\vegastrike\vegastrike\boost\1_45\src\converter\builtin_converters.o:builtin_converters.cpp|| undefined reference to `_imp__PyExc_OverflowError'|
||=== Build finished: 28 errors, 1 warnings ===|

Guess I need to compile python now, huh?

Downloading and setting up python 2.7.3
Preemptively after that I will install SDL-1.2.15 and freealut-1.1.0

Posted: **Sat Nov 24, 2012 1:01 am**

15. Grr I forgot that python doesn't compile straightforward on mingw. There's a port of python to mingw at http://mingw-and-ndk.googlecode.com/fil ... n-mingw.7z (it's python 2.7.1 so I think it will do) Installing this and testing before moving forward.

(edit) Still get the same errors as above. I even explicitly added the path where python is installed to the build properties (mingw/include and mingw/lib) and still I can't get over those.

Posted: **Sat Nov 24, 2012 2:51 am**

There do not seem to be any references in the code to YY_ALWAYS_INTERACTIVE

Also, only two files are actually included in the windows project of the 3 cpp files an no found reference to the only used file

calike.tab.cpp

Code: Select all

#include <string>
#include <stdio.h>
using std::string;
bool have_yy_error=false;
string parseCalike(char const *filename)
{
	return "";
}

int yylineno=0;
int yyerror(char *s){
  printf("(yy)error:  line %d text --\n",yylineno+1);

  return 1;
}

int yywrap(){
	return 1;
}


int yylex() {
	return 1;
}

reference in easydom.h but no include file for the function out of the above file...

Code: Select all

    domNodeType * LoadCalike( const char *filename )
    {
        const int chunk_size = 262144;

        string    module_str = parseCalike( filename );
        if ( module_str.empty() )
            //cout << "warning: could not open file: " << filename << endl;
            //assert(0);
            return NULL;
        xml = new easyDomFactoryXML;
*snip*

So far based on the last reference to calike I think this was used in early AI code.

Posted: **Sat Nov 24, 2012 3:21 am**

Yes, it was a c-like script.

Posted: **Sat Nov 24, 2012 4:46 am**

So... is any of it still in use? It doesn't look like any of the yacc/lex items are used anymore.

Posted: **Sat Nov 24, 2012 5:41 am**

Yeah, I think not. We should check before removing it though.

Vega Strike Forums

Mingw: the Nov 2012 attempt

Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt

Re: Mingw: the Nov 2012 attempt