• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
serratemplar

SDL2, mingw64, and Code::Blocks

19 posts in this topic

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. smile.png 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. sad.png

 

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. smile.png

 

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!

1

Share this post


Link to post
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?

1

Share this post


Link to post
Share on other sites

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

 

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.

2

Share this post


Link to post
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.

1

Share this post


Link to post
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.

1

Share this post


Link to post
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!

2

Share this post


Link to post
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?)

1

Share this post


Link to post
Share on other sites

I respect your positions, haha. You make very good points. smile.png 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).

2

Share this post


Link to post
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.

1

Share this post


Link to post
Share on other sites

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

2

Share this post


Link to post
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.

1

Share this post


Link to post
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|

If I remember correctly, MinGW follows UNIX standards, so options start with - and --, while Microsoft's tools follow DOS standards - so options start with /.

 

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.

1

Share this post


Link to post
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. :)

1

Share this post


Link to post
Share on other sites

Thanks Ultra and Georger. smile.png 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. smile.png

 

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

 

I've made a VS2013EE template for 32-bit SDL2 applications as well (download link at the end of the linked forum thread).

1

Share this post


Link to post
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.

1

Share this post


Link to post
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.

1

Share this post


Link to post
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.

1

Share this post


Link to post
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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0