Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


SDL2, mingw64, and Code::Blocks


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
19 replies to this topic

#1 thade   Members   -  Reputation: 1652

Like
1Likes
Like

Posted 24 March 2014 - 09:24 PM

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!


I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


Sponsor:

#2 georger.araujo   Members   -  Reputation: 849

Like
2Likes
Like

Posted 24 March 2014 - 10:13 PM

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.


Edited by georger.araujo, 24 March 2014 - 10:51 PM.


#3 georger.araujo   Members   -  Reputation: 849

Like
2Likes
Like

Posted 24 March 2014 - 10:32 PM

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.

 

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.



#4 thade   Members   -  Reputation: 1652

Like
1Likes
Like

Posted 25 March 2014 - 08:34 AM

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?


I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#5 georger.araujo   Members   -  Reputation: 849

Like
1Likes
Like

Posted 25 March 2014 - 11:45 AM

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.



#6 thade   Members   -  Reputation: 1652

Like
1Likes
Like

Posted 25 March 2014 - 01:31 PM

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.


I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#7 thade   Members   -  Reputation: 1652

Like
1Likes
Like

Posted 25 March 2014 - 01:38 PM

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.


I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#8 georger.araujo   Members   -  Reputation: 849

Like
1Likes
Like

Posted 25 March 2014 - 02:03 PM

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!



#9 thade   Members   -  Reputation: 1652

Like
1Likes
Like

Posted 25 March 2014 - 02:11 PM

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 previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#10 georger.araujo   Members   -  Reputation: 849

Like
2Likes
Like

Posted 25 March 2014 - 02:34 PM

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



#11 thade   Members   -  Reputation: 1652

Like
1Likes
Like

Posted 25 March 2014 - 02:58 PM

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.


I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#12 ultramailman   Prime Members   -  Reputation: 1654

Like
2Likes
Like

Posted 25 March 2014 - 04:23 PM

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



#13 georger.araujo   Members   -  Reputation: 849

Like
1Likes
Like

Posted 25 March 2014 - 04:33 PM

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.



#14 dilyan_rusev   Members   -  Reputation: 1159

Like
1Likes
Like

Posted 26 March 2014 - 03:42 AM

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.



#15 thade   Members   -  Reputation: 1652

Like
1Likes
Like

Posted 26 March 2014 - 07:42 AM

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


I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#16 georger.araujo   Members   -  Reputation: 849

Like
1Likes
Like

Posted 26 March 2014 - 03:21 PM

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



#17 dilyan_rusev   Members   -  Reputation: 1159

Like
1Likes
Like

Posted 27 March 2014 - 09:30 AM

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



#18 georger.araujo   Members   -  Reputation: 849

Like
1Likes
Like

Posted 27 March 2014 - 10:07 AM

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.



#19 thade   Members   -  Reputation: 1652

Like
1Likes
Like

Posted 27 March 2014 - 10:31 AM

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.


I was previously serratemplar; a name I forfeited to share a name with an angry rank-bearing monkey.

http://thadeshammer.wordpress.com/


#20 dilyan_rusev   Members   -  Reputation: 1159

Like
0Likes
Like

Posted 31 March 2014 - 02:41 AM


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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS