User forums > Using Code::Blocks

win32 compile problem

<< < (2/4) > >>

thomas:
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.

bootstrap:
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.

bootstrap:

--- Quote from: thomas 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.
--- End quote ---
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"?

Jenna:

--- Quote from: bootstrap on January 27, 2009, 09:54:12 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.

--- End quote ---

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.

bootstrap:
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

Navigation

[0] Message Index

[#] Next page

[*] Previous page