This warning is a new one on me. I am trying to build a shockingly simple SDL2 app with Code::Blocks and mingw64 and here's what I'm getting:

||Warning: .drectve `/manifestdependency:"type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='amd64' publicKeyToken='1fc8b3b9a1e18e3b'" /DEFAULTLIB:"MSVCRT" /DEFAULTLIB:"OLDNAMES" ' unrecognized|

My Googlefu has failed me and I'm totally out of ideas. I'm hoping that, if I list out everything I've learned and seen so far, maybe one of you all will see what I'm missing.

The source is super-simple. It's just this:

#include "SDL.h"

int main(int argc, char* args[]) {
    //SDL_Init(SDL_INIT_EVERYTHING);

    //exit(SDL_Quit());
    return 0;
}

YES those two function calls are commented out; the warning is only thanks to the #include of SDL.h.

I do have quite a few VS redists installed (including one with the exact version number in that warning), but I don't think that's really connected here. This post (here on Gamedev) and this post (from the SDL forums) seem to imply that I'm (accidentally) trying to link either

mingw SDL against VS libs

OR

VS SDL against mingw libs

Then in this spectacularly frustrating post, a user puts up an error very, very similar to mine (same warning, different version, and some actual errors) but then shortly after posts that they fixed it...so the solution is never shared.

I installed mingw-64 (which is the only mingw on my system) but it's worth mentioning that VS 2010 is also on here. I've pointed Code::Blocks at mingw; it's on the path and the only "g++" on my system, so that's got to be what it's running.

I would like to play around with SDL2, so I grabbed SDL2-devel-2.0.3-mingw.tar.gz which, on the site, is linked beside the MinGW64 that I downloaded. I.E., inspite of what the warning is telling me it appears to me that I am in fact trying to use mingw libs with a mingw compiler. Maybe this is somehow a 32-bit vs. 64-bit issue? (Again, it looks to me like it's not, and I did try throwing -m64 into the options; it had no effect.) Or maybe I'm just way more wrong than I think I am.

I used sdl-config to get the cflags and libs appends but here's the first catch; I couldn't run these in Windows (it gave me a "These are 16-bit" errors) so I ran them in my Cygwin window. (I'm mostly certain this is okay, but including it here anyway.)

sdl-config --cflags gave me

-I/usr/local/cross-tools/x86_64-w64-mingw32/include/SDL2 -Dmain=SDL_main

sdl-config --libs gave me

-L/usr/local/cross-tools/x86_64-w64-mingw32/lib -lmingw32 -lSDL2main -lSDL2 -mwindows

I translated those /usr/local/cross-tools/ paths to Windows paths, pointing at the pre-compiled ones that I unpacked with the rest of SDL 2.0.3, thus:

-IF:\SDL\SDL2-2.0.3\x86_64-w64-mingw32\include\SDL2
-LF:\SDL\SDL2-2.0.3\x86_64-w64-mingw32\lib

It occurred to me that possibly I need to build the libs myself, so I installed Make for Windows and tried that and ran into some problems. (This is where I reveal to you what a giant noob I am with make.)

f:\SDL\SDL2-2.0.3>make native
make install-package arch=i686-w64-mingw32 prefix=/usr
make[1]: Entering directory `f:/SDL/SDL2-2.0.3'
-d was unexpected at this time.
make[1]: *** [install-package] Error 255
make[1]: Leaving directory `f:/SDL/SDL2-2.0.3'
make: *** [native] Error 2

The "native" specificer there seems to be trying to crank out 32-bit, when I would prefer 64-bit; perhaps that's just the first step, but I'm not sure. The only page I found on "-d was unexpected" was this StackOverflow post that looked like I'd need to debug SDL2's makefile, which I wished to avoid. I did try "cross" which gave me an even fancier error.

f:\SDL\SDL2-2.0.3>make cross
for arch in i686-w64-mingw32 x86_64-w64-mingw32; do \
            make install-package arch=$arch prefix=/usr/local/cross-tools/$arch;
 \
        done
arch was unexpected at this time.
make: *** [cross] Error 255

I'm at a loss and I'm very hopeful that one of you has possibly encountered this (or something like it) before and can spot what I've missed or done incorrectly here.

Thank you in advance!

Those error messages make it look like you're mixing VS flags with GCC?

You don't need all that work to compile your program. I suggest the following:

- Delete your current MinGW-w64 installation, we'll replace it with the one bundled with Code::Blocks.

- Uninstall Code::Blocks. Delete C:\Users\thade\AppData\Roaming\CodeBlocks (change your user name as appropriate) to get rid of any possibly wrong settings, download the Code::Blocks + TDM-GCC bundle, and install it;

- Download and install SDL2 (the same .tar.gz you already downloaded), and unpack it to the directory of your choice (I use C:\SDL2-2.0.3);

- Run Code::Blocks. Click Settings, Global Variables..., create a new variable named sdl2, and point its base field to C:\SDL2-2.0.3\i686-w64-mingw32

- Download and install my SDL2 project wizard for Code::Blocks.

Then create a new project with the "SDL2 project" template, and it should work.

I installed mingw-64 (which is the only mingw on my system) but it's worth mentioning that VS 2010 is also on here. I've pointed Code::Blocks at mingw; it's on the path and the only "g++" on my system, so that's got to be what it's running.

I would like to play around with SDL2, so I grabbed SDL2-devel-2.0.3-mingw.tar.gz which, on the site, is linked beside the MinGW64 that I downloaded. I.E., inspite of what the warning is telling me it appears to me that I am in fact trying to use mingw libs with a mingw compiler. Maybe this is somehow a 32-bit vs. 64-bit issue? (Again, it looks to me like it's not, and I did try throwing -m64 into the options; it had no effect.) Or maybe I'm just way more wrong than I think I am.

There's no need to install a particular flavor of MinGW, SDL is a C library and therefore it's ABI-compatible with other MinGW compilers. Actually, I believe the official SDL distribution is not even compiled on Windows, but rather cross-compiled on Linux. I have used both SDL 1.2.15 and SDL 2.0.3 with both MinGW32 and TDM-GCC just fine.

As for the 32-bit vs. 64-bit issue, well, it's not an issue: under the folder where you unpacked SDL2, there are BOTH the i686-w64-mingw32 (32-bit) and x86_64-w64-mingw32 (64-bit) folders, each with their own bin and lib subfolders. That's why I instructed you in my other reply to point you Code::Blocks sdl2 global variable to C:\SDL2-2.0.3\i686-w64-mingw32 - so that you'll use the 32-bit SDL2 build, which matches the 32-bit TDM-GCC that is bundled with Code::Blocks.

Thank's for taking time to respond in such detail. :)

I could certainly restart the setup from scratch, which - I admit - is pretty appealing right now.

The reason I installed mingw-w64 is that I was lead to believe (perhaps erroneously) that standard mingw (the one that ships with Code::Blocks) won't build for 64-bit, which I very much want. I also want full support for the C++ 11 spec and an "easy" time of cross-compiling for various OSs, which is what lead me to g++ in the first place. Maybe one of my assumptions here is incorrect?

Thank's for taking time to respond in such detail.

I could certainly restart the setup from scratch, which - I admit - is pretty appealing right now.

The reason I installed mingw-w64 is that I was lead to believe (perhaps erroneously) that standard mingw (the one that ships with Code::Blocks) won't build for 64-bit, which I very much want. I also want full support for the C++ 11 spec and an "easy" time of cross-compiling for various OSs, which is what lead me to g++ in the first place. Maybe one of my assumptions here is incorrect?

Hi,

I once tried MinGW-w64, and couldn't get it work right. I came back to TDM-GCC, which worked right out of the box. So, consider uninstalling both MinGW-w64 and Code::Blocks, and installing the bundle. It's very simple and straightforward.

Do you have compelling reasons for going 64-bit? The SFML download page does a good job of explaining this:

"On Windows, choosing 32 or 64 bits libraries should be based on which platform you want to compile for, not which OS you have. Indeed, you can perfectly compile and run a 32 bits program on a 64 bits Windows. So you'll most likely want to target 32 bits platforms, to have the largest possible audience. Choose 64 bits packages only if you have good reasons."

I don't know if TDM32 (the one bundled with Code::Blocks) can build 64-bit programs. I personally use TDM64 and, as suggested on the SFML download page, build 32-bit programs with it, since it has "Overall improved Windows 7 and 8 win32 API support" over "official" MinGW (which TDM32 is based on). This way I get the best from both worlds: I have better API support, and I don't have to recompile all of my libraries in 64-bit mode. That said, I had to complement my TDM64 install with 32-bit GDB, since the one shipped with TDM64 won't debug 32-bit programs.

I suppose I'm not sure whether I have a compelling reason to push for 64-bit, other than my understanding that it's ubiquitous for PCs now. Otherwise, my reasons are likely (gross) overestimations. For instance, 2 GB as a hard ceiling is still a lot of memory to work with.

I'd still be curious to figure out what that initial warning means, for my own edification if nothing else.

Doing more digging now that I have time to. Stripping a lot of the specifics out of that initial warning and Googling further is generating more hits (as you might expect).

One comment I found is telling: "Do you think it's because your prebuilt libraries were build unter Visual Studio 2008 and I'm using Eclipse?"

I have a hypothesis: that the SDL dlls I have pre-built were in fact built with Visual Studio 20xx, and that is why the error is about MSVCRT; I bet if I can manage to build my own SDL libs with Code::Blocks this will work.

Doing more digging now that I have time to. Stripping a lot of the specifics out of that initial warning and Googling further is generating more hits (as you might expect).

One comment I found is telling: "Do you think it's because your prebuilt libraries were build unter Visual Studio 2008 and I'm using Eclipse?"

I have a hypothesis: that the SDL dlls I have pre-built were in fact built with Visual Studio 20xx, and that is why the error is about MSVCRT; I bet if I can manage to build my own SDL libs with Code::Blocks this will work.

Why would you go through the trouble of building SDL yourself if they offer the development libraries pre-built at their website?

Worse, you need more than Code::Blocks in order to build SDL: you'll need the sources and SDKs to the supporting libraries (e.g. zlib, FreeType, and DirectX), AND more toolchain utilities (e.g. mingw32-make, or even MSYS).

SDL is a C library, the ABI is standardized. It's not like C++ libraries where you have to worry about the compiler version and exception model - to illustrate, I've used the pre-built Visual C++ development libraries ob both VS2010 and VS2013, with no issues. Get the pre-built development libraries, stop worrying, and start coding!

I respect your positions, haha. You make very good points. :) Certainly it would be far easier to throw in the towel here and just fire up Visual Studio again.

That said, I'd like to push at this a bit more before giving up. The reason I go through the trouble is the experience; I learn a great deal fighting with stuff like this. (Don't we all?)

I respect your positions, haha. You make very good points. Certainly it would be far easier to throw in the towel here and just fire up Visual Studio again.

That said, I'd like to push at this a bit more before giving up. The reason I go through the trouble is the experience; I learn a great deal fighting with stuff like this. (Don't we all?)

I was under the impression that all you wanted was to write an SDL2 application with MinGW and Code::Blocks. If you also want to build SDL, all the better, it will be a rewarding (and painful, I suppose) learning experience!

I should also mention that, while SDL is a C API and you can use it regardless of your compiler version, you should still take note that you have to use the appropriate compiler, and can't use the MinGW pre-built development libraries with Visual Studio (and vice versa).