User forums > Using Code::Blocks

win32 compile problem

(1/4) > >>

bootstrap:
I am developing a cross-platform 3D game/graphics/simulation engine and am trying to switch from my old IDEs to CodeBlocks.  With some help from this forum, I can now compile, execute, debug my engine with CodeBlocks on Linux.  Hurray!  Send eclipse to the trash-can!

Unfortunately, now I have problems compiling the code with CodeBlocks on Windoze.  Sorry to bother you again, but I'm going in circles.  Here are the facts that seem most relevant, and my current symptom.

First, understand that *this* portable application is not portable in the same way as many others (ala cygwin, I suspect).  What I mean is, my code contains #ifdef LINUX and #ifdef WINDOZE around any and all code (and #includes) that cannot be identical on both OS - and does *not* in any way expect or depend upon emulating linux on windoze, or emulating windoze on linux.  Perhaps the best way to say that is, the code compiles and runs in VisualStudio2005pro *and* CodeBlocks on Linux at this point, the only difference being LINUX is defined (in the IDE) on Linux, and WINDOZE is defined (in the IDE) on Windoze (in both VisualStudio2005 and CodeBlocks).  Since I am trying to compile with the same GCC compiler and toolset on both OS with CodeBlocks, all the compiler switches remain the same as CodeBlocks on Linux.

Okay.  I suspect I have some problem with default include paths, but maybe not.  I currently have: Settings => CompilerAndDebugger => SearchDirectories pointing to the "c:/Program Files (x86)/Microsoft Visual Studio 8/vc/include", since I am compiling and executing in 32-bit mode first (to avoid asking for even more problems).

The first compile error that appears is in system header file <wchar.h> which my application does include from 3 or 4 files.  It generates the following error a zillion times:

error: '__time64_t' does not name a type

The __time64_t type is created in <time.h>, but sure enough <wchar.h> does not include <time.h>, only <crtdefs.h> (which does not include <time.h> either, as far as I can tell).

Somehow, this leaves me confused.  Surely macroshaft header files are responsible for including any other header files they need to compile correctly.  And sure enough, this same (as in identical) code compiles correctly when compiled by VisualStudio2005.

I read somewhere (on the mingw website, probably) that mingw implementation of the GCC toolset is appropriate for compiling/building "native win32 applications", and is different in that way from cygwin and similar "emulation layer" approaches.  Soooo, I just don't understand, though I suspect someone will immediately point out "why I should".  And they are probably correct too!  Too bad I don't "get it".  Please clarify for this dummy.  Thanks.

PS: It is generating lots more errors inside <wchar.h> too, but probably they will vanish whenever the "stupid mistake" I am making is fixed.  Let's hope so.

Jenna:
You can not use the VS-includes and libs with gcc.

MinGW cames with it's own set of headers and libs.
If you use gcc (MinGW) on windows, you only should include gcc's headers (and the ones of foreign libs you use, if they are compatible/built for gcc).

Normally MinGW finds it own includes and libs without explicitely set the search dir.

The most (not necessary all) things should work out of the box if you compile identical code on linux and win, except for foreign libs.

MortenMacFly:

--- Quote from: bootstrap on January 27, 2009, 05:07:08 am ---Unfortunately, now I have problems compiling the code with CodeBlocks on Windoze.

--- End quote ---
You won't be able to switch from VC compiler to MinGW/GCC compiler without (heavy) modifications and probably even the need of 3rd party libs I guess. But why don't you just use the VC compiler with C::B?

Jenna:

--- Quote ---I can now compile, execute, debug my engine with CodeBlocks on Linux.
--- End quote ---
If I read right, he managed to compile the same code on linux, so I think it should be possible to fix it for MinGW, too.

thomas:
You very likely clicked on "Have g++ follow the 1998 C++ standard". This enables strict ANSI mode in which it isn't allowed to use non-standard C names such as the ones defined in <sys/types.h>.
Solution: either write compliant C++ or do not tell the compiler to treat your code as such.

Navigation

[0] Message Index

[#] Next page