# SDL2, mingw64, and Code::Blocks

This topic is 1394 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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.

##### Share on other sites

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;

- 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

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

Edited by georger.araujo

##### Share on other sites
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.

##### Share on other sites

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?

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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!

##### Share on other sites

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?)

##### Share on other sites

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).

##### Share on other sites

Make no mistake, you've been very helpful; I'm grateful.

If I understand you're cautionary note there, it sounds as if the rabbit hole maybe goes deeper than I first realized. Initially I made the (unconscious) assumption that the pre-built SDL2 libs I grabbed were built with mingw/g++...but in reality I think it's more likely they were built with VS. Now I realize I've made the same assumption about mingw-w64 itself. @_@ Possibly it too was built with VS (to function easily in Windows) which may further stymie my efforts here.

Whew, haha.

##### Share on other sites

Building SDL2 using mingw was pretty simple, it's just a cmake -G"MinGW Makefiles" followed by a mingw32-make.

##### Share on other sites

Building SDL2 using mingw was pretty simple, it's just a cmake -G"MinGW Makefiles" followed by a mingw32-make.

Nice!

@thade: you can download CMake, an open-source build system, here. Try and build SFML from source (both Debug and Release) as well, you'll gain useful knowledge in the process.

##### Share on other sites

If you still want an answer to the original question...

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


I'm not a command-line expert, but these seem to be linker options for Visual Studio's toolset. Go around Code::Blocks settings and get rid of them, if possible. If you can't find them, open the Code::Blocks project file with a text editor, find and delete them. This should fix the problem.

##### Share on other sites

Thanks Ultra and Georger. :) I'll give cmake a whirl and check back in.

@dilyan, I think what you're saying is /manifestdependency and /DEFAULTLIB are options, and you're suggesting the fix is to remove those options (instead of trying to find alternatives)?

Full-disclosure: after another round with this last night, I took georger's advice to heart...I set up Visual Studio 2013 (upgrading from '10) and got to work, which was a breath of fresh air haha. :)

Thank you all for your time and brainpower; I learned a lot suffering through this. :)

##### Share on other sites

Thanks Ultra and Georger. I'll give cmake a whirl and check back in.

@dilyan, I think what you're saying is /manifestdependency and /DEFAULTLIB are options, and you're suggesting the fix is to remove those options (instead of trying to find alternatives)?

Full-disclosure: after another round with this last night, I took georger's advice to heart...I set up Visual Studio 2013 (upgrading from '10) and got to work, which was a breath of fresh air haha.

Thank you all for your time and brainpower; I learned a lot suffering through this.

##### Share on other sites

@dilyan, I think what you're saying is /manifestdependency and /DEFAULTLIB are options, and you're suggesting the fix is to remove those options (instead of trying to find alternatives)?

They are options (or command-line flags, arguments, parameters, whatever). Some of them I recognize as linker options. For some reason, you've got them passed down to your MinGW linker, and it complains that they are unfamiliar to it.

I do not recommend that you go back to Code::Blocks. This was intended as an answer to your original question, in case you were still curious.

##### Share on other sites
I do not recommend that you go back to Code::Blocks. This was intended as an answer to your original question, in case you were still curious.

Why not? For people who don't want to or can't use Microsoft's SDK and opt to use GCC instead, it's pretty decent.

##### Share on other sites

I don't mind Code::Blocks; I like that it spits out all of it's command-line fu so clearly (and that it doesn't marry me to the nightmarish telescoping makefiles of Visual Studio). VS's IDE is far superior and I'm far more used to it to boot, but as IDEs go I don't mind it.

##### Share on other sites

Why not? For people who don't want to or can't use Microsoft's SDK and opt to use GCC instead, it's pretty decent.

I said "I do not recommend" as in "this isn't what I wanted to say". I was quite curious, so I've used all IDEs I could find, and there are a lot of them. From the free IDEs I liked QtCreator and Eclipse the most. But this is much like saying I prefer blonde blue-eyed women.