Author Topic: win32 compile problem  (Read 15564 times)

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
win32 compile problem
« on: January 27, 2009, 05:07:08 am »
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.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: win32 compile problem
« Reply #1 on: January 27, 2009, 07:06:27 am »
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.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9493
Re: win32 compile problem
« Reply #2 on: January 27, 2009, 07:29:02 am »
Unfortunately, now I have problems compiling the code with CodeBlocks on Windoze.
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?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: win32 compile problem
« Reply #3 on: January 27, 2009, 07:54:36 am »
Quote
I can now compile, execute, debug my engine with CodeBlocks on Linux.
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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: win32 compile problem
« Reply #4 on: January 27, 2009, 12:42:10 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: win32 compile problem
« Reply #5 on: January 27, 2009, 01:01:23 pm »
As a sidenote, some of you (like me) may have found the shiny features of C++0x nice and thus added -std=c++0x in their global compiler options. That is a brilliant idea, except after a while you will try to compile Code::Blocks and find that it doesn't build any more! This is due to the use of popen() in autorevision (which unluckily is just the only thing that's easy, cross-platform, and that just works).
This is a very similar issue to the one above, and can be solved by using -std=c++0x -U__STRICT_ANSI__. While this is kind of a nasty hack, and surely not what the gcc guys intended, it works perfectly well.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
re: win32 compile problem
« Reply #6 on: January 27, 2009, 09:54:12 pm »
I don't want to waste any busy CodeBlocks developer time, so if that describes you, just ignore this question.  And for that matter, anyone else whose time is slightly less critical (or you are a willing victim), feel free to provide one (or a few) links to websites that answer my question.  I already looked in wikipedia, but that doesn't mean I understand everything they say.  As background, this is the first text on the http://www.mingw.org webpage:

MinGW: A collection of freely available and freely distributable Windows specific header files and import libraries, augmenting the GNU Compiler Collection, (GCC), and its associated tools, (GNU binutils). MinGW provides a complete Open Source programming tool set which is suitable for the development of native Windows programs that do not depend on any 3rd-party C runtime DLLs.

The italics (which I added) says what may be misleading my feeble comprehension.  Even though I've written compilers and IDEs myself, I am quite dumb about common conventions - except those I adopt and work with every day.  So I read (past tense) that statement to mean "you can take your working native win32 application and develop it with the mingw toolset on windoze".  That is apparently my mistake, though I still do not quite understand why any C/C++ compiler cannot compile valid C/C++ headers and .cpp files no matter who provides them.  Probably the messages above should make me understand the reason, but my density is too great.

Soooo, any links to articles or books or other resources that explain?

PS:  Someone asked "why not compile with VS or the VS compiler and tools"?  The answer is, I can.  But it seems an increasing number of people are getting interested in my "procedurally generated content" 3D game/graphics/simulation engine, and want to develop [or enhance] various subsystems for it.  Many are working on Linux, and CodeBlocks already compiles, executes, debugs my engine perfectly well on Linux (hence I can now throw eclipse away).  However, some of these developers have windoze computers and therefore need/want to develop in windoze.  While one new developer is "willing" to develop in VS, everyone else prefers to stay away from "evil empire tools" for various reasons (even free ones).  In fact, it is they who got me to switch to CodeBlocks on Linux (!!!good move!!!), and we (me too) were hoping to abandon VS entirely --- for our own development anyway.  Hopefully all this helps to clarify my/our "problem", and why we prefer to make windoze CodeBlocks compile the code without massive rework.  Furthermore, this application *cannot* afford efficiency loss due to emulation layers, so the code will always need to be "native on linux" and "native on windoze" via the #ifdef LINUX and #ifdef WINDOZE statements in the code.  Frankly, virtually all OS-dependent code is behind me already, so "the work/hassle is done" and I am not in a mood to go to lots of effort to reduce efficiency!!!  Nope.  I didn't write a bunch of SIMD/SSE3+ assembly language in both MASM and "as/linux" style just to throw that efficiency away.  I will study the answers above further, but I suspect I need more information to understand the mess I got myself into here.  Nonetheless, in the worse case scenario, I guess the suggestion someone made to run the free macroshaft C compiler inside CodeBlocks is a possible, albeit unfavored, worst case scenario.  Thanks, everyone.
« Last Edit: January 27, 2009, 10:01:25 pm by bootstrap »

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
Re: win32 compile problem
« Reply #7 on: January 27, 2009, 10:15:12 pm »
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.
No, I did not click that option, and in fact cannot find it in any CodeBlocks dialog (maybe I need to find that dialog?).  I did see an option that outputs -ansi compiler switch, but I do not have that checked either (though I tried it at one point).

I'm not sure what is "complant C++", exactly.  However, I would be surprised to find that my code is not compliant, since all my code is just "plain, straightforward C" with [very] few C++ conveniences.  In fact, about the only ones are // comments and declarations of variables after the first executable statement.  Oh, and I guess I declared some math constants in typed const statements rather than untyped #define statements.  Surely none of these vanilla features makes my code "non-compliant".  My code has no classes, no templates, no function/argument overloading, and nothing fancy *at all*.  Or is such simple code somehow "non-compliant"?

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: win32 compile problem
« Reply #8 on: January 27, 2009, 10:17:07 pm »
MinGW: A collection of freely available and freely distributable Windows specific header files and import libraries, augmenting the GNU Compiler Collection, (GCC), and its associated tools, (GNU binutils). MinGW provides a complete Open Source programming tool set which is suitable for the development of native Windows programs that do not depend on any 3rd-party C runtime DLLs.

That means MinGW has everything included to build a native windows program, without the need of any libs that does not ship with standard windows.

The VS8 SDK is a software development kit created for the use with VS8 and not any other compiler, it uses special statements, defines, hacks and whatever, that only works with VS8.
MinGW uses the native windows api, and therefore ships with own header-files and libraries and provides everything you need to build and run stadard c++/c code.

Have a look at the win32-gui-project wizard of C::B. It does not use, nor need any of the VS-files but creates areally native windows application.

If you code compiles on linux, it should also be possible to compile it with MinGW, assumed you don't use any linux-specific gui elements, or libs that are not available on windows.

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
re: win32 compile problem
« Reply #9 on: January 28, 2009, 01:45:51 am »
Okay, so that must mean mingw comes with dozens or hundred of header files that contain the same win32 API function declarations, structure declarations, constant definitions, and so forth.

So, did they do "the obvious thing" (or obvious to me, anyway), which is to "allow all #include statements that refer to win32 API functions/structures/constants/etc" remain identical - AND - only require the header search path be different (to find the wingw32 versions)?

Or, did they require win32 programs be totally revamped to include different header files?

I will try what you suggest, but I think I already did that, and it failed.  So I guess now I will remove all windoze/win32 specific search paths (and everything else), rediscover why that approach did not work, and report my problems here.

Just to be super-clear.  When compiled with LINUX defined (in the IDE in the #define tab), the #ifdef LINUX blocks in my code creates windows via the lowest-level xlib XWindows function calls I could find.  Ditto for every kind of create/query/configure/destroy function for OS-specific entities like "GPU", "display", "window" (some via the GLX subsystem of XWindows, which supports OpenGL).  When compiled with WINDOZE defined (in the IDE in the #define tab), the #ifdef WINDOZE blocks in my code does all the above via totally conventional win32 API function calls.

So my engine actually *is* two engines - one for linux, one for windoze (though both based upon OpenGL) - with those #ifdef LINUX/WINDOZE statements deciding which contents of my functions are compiled on each OS.  Of course, you really can't tell this from the "outside", because all OS-specific code is inside functions like "ig_window_create()"... which give no clue which OS (or graphics subsystem either, in fact) is creating/resizing/destroying windows, or creating/rotating/moving 3D objects, or doing collision-detection, or anything else.

The *interface* is totally "everthing independent", but it contains two sets of code for OS-specific functionality.  However, what may not be obvious to folks who have not created such an engine, the OS-specific portion is only about 1% now, and will become 0.1% later, and in the long, long term eventually, probably less than 0.0001% or so.  In fact, though the engine can "direct [static or shared] link" to any application that wants these capabilities at maximum speed, the engine can be driven by 100% identical client/application code through a "sockets/network layer"... so the client/application and server/engine literally can be totally different (different CPU, different OS, different endian, different programming language, different human language, different # of bit CPU, different <fill in the blank>).

Yes, everyone tells me I am totally crazy to write all this lowest-possible-level-OS-dependent-code myself - that I should save myself the time and effort by adopting some layer or framework.  Sorry, been there, done that, got badly burned every time I depended upon every kind of "make it easier for me" promise.  And every time I program at the absolute lowest level I can, it not only "works", but is vastly easier to understand, vastly more reliable, much faster, and nothing is *ever* hidden from me or beyond my control (until we enter the realm of the GPU innards, which my GPU shaders [and GPUPU code] deal with to the extent practical).  So I can find, understand and fix problems and/or enhance anything in any way I wish, at any time - to the extent possible at all.  So, just warning everyone, don't bother to suggest I "get conventional" in this way.  Not gonna happen.  But thanks for helping me figure out these problems, and thanks for all advice you care to give (except that one issue, where you are wasting your time on one intransigent doofus).

Oh, BTW, the only "external library" I adopt in my engine (so far) is OpenGL (though soon I may be forced to adopt some low-level sound library to avoid device-specific sound-programming).  Do I get access to that simply via the glee.h and glee.c packages?  Or what?  Where should those be included from or where should I move a copy of the following files to?    gl.h   glx.h   glext.h   glxext.h

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
re: win32 compile problem
« Reply #10 on: January 28, 2009, 02:47:16 am »
You know what?  I wonder whether I have any w32api headers installed at all.

When I downloaded the CodeBlocks binary package, I downloaded the large "everything" package that I thought included everything necessary to build win32 applications with CodeBlocks and mingw32.  But I wonder... where are those mingw32 header files supposed to be on my computer, so I can make sure they exist?

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
re: win32 compile problem
« Reply #11 on: January 28, 2009, 03:11:16 am »
Well, I just installed mingw with their automatic installer, which definitely created a c:/mingw directory with "include" and other subdirectories, so no question about that any longer.  Even when I put c:/mingw/include in the "default search path" list, it does not seem to find them.

For example, the first error appears in one of my files that contains:

#include <malloc.h>

near the top, but still generates errors on the following two lines:

  data = (u08*) _aligned_malloc (bytes, 16);

and

  if (buffer) { _aligned_free (buffer); }

...even though I look inside c:/mingw/include/malloc.h and find those functions *are* declared.  The error messages say:

error: '_aligned_malloc' was not declared in this scope
error: '_aligned_free' was not declared in this scope

Then, dork that I am, I tried adding

#include "c:/mingw/include/malloc.h"

at the top of my file, and it *still* generates the same exact errors (see above).

Wow!  Got me, batman!

I am beginning to feel un-freaking-believably stupid!!!  But I just don't know why, yet.  :-(
« Last Edit: January 28, 2009, 03:12:51 am by bootstrap »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9493
Re: re: win32 compile problem
« Reply #12 on: January 28, 2009, 07:07:30 am »
  data = (u08*) _aligned_malloc (bytes, 16);
Are you aware that these prototypes are within an ifdef statement:
Code: [Select]
/* These require msvcr70.dll or higher. */
#if __MSVCRT_VERSION__ >= 0x0700
[...]
#endif
???
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
re: win32 compile problem
« Reply #13 on: January 28, 2009, 08:13:29 am »
Eh, no, I didn't notice that, but you raise a question.

My code compiles and runs the way it is on VisualStudio2005.  Roughly how many "extra" #defines (that I don't have now and don't need in VS) am I likely to need to add?  And, do they belong in the #define tab in the IDE, or in my code somewhere?

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: re: win32 compile problem
« Reply #14 on: January 28, 2009, 09:00:56 am »
Eh, no, I didn't notice that, but you raise a question.

My code compiles and runs the way it is on VisualStudio2005.  Roughly how many "extra" #defines (that I don't have now and don't need in VS) am I likely to need to add?  And, do they belong in the #define tab in the IDE, or in my code somewhere?

Add the following

Code: [Select]
__MSVCRT_VERSION__=0x0700
to Project > Build options... > #defines
Be a part of the solution, not a part of the problem.