I have allegro5 library i want to install it in dev cpp 4.9.9.2 but i unabled.plz can anybody help me
Don't use Dev-Cpp. Causes more problems than it solves. Use Code::Blocks instead. It's as beginner friendly as Dev-C++ and much better.
You can choose to either build Allegro 5 from source or use precompiled binaries(recommended for beginners). For using the binaries, go here and download the binaries for your compiler(if you're unsure, just pick the lowest version for mingw, it should work fine).
Follow the instructions from this wiki tutorial. Note that the precompiled binaries include an special allegro lib called "monolith" version, which will link ALL the allegro libraries(addons as well) so you don't have to even bother with all those linker options. Makes it much easier to distribute your game as well if you're using dynamic linking, just gotta bundle the monolith dll with it.
Better yet, skip Dev-C++, skip Code::Blocks and use free Visual C++ 2010 Express.
I feel this version is still better than 2010. Maybe the 2011 or 2012 version will have caught up, but I'd go with 2008 for now. The focus of the 2010 version was porting it to .NET. In that process, some things (like performance) were lost. Yay for Microsoft dogfooding .NET
I prefer Code::Blocks when I just need to code a little application, since it doesn't take as much time as MSVC to boot up, and the building time is way faster. It wasn't so bad with 2008.
I also recommended C::B because it seems the OP was going for mingw as compiler using Dev-C++. You can also open your .cbp projects on Linux.
I had a lot of issues with Visual C++ 2010 Express until Service Pack 1 was released. After SP1 it's rock solid for me. Sure it's using way too much RAM and 2008->2010 WPF rewrite was kind of a lame marketing thing, BUT. What you get with Visual C++ 2010 Express is the latest MSVC compiler with some great C++11 support (like "auto" keyword and built-in smart pointers).
I've been trying to ditch Dev-C++ in favour of Code::Blocks but I can't get it to freaking work. I've linked to everything properly, added all the linker and compiler options like the guide on the wiki said to do (and all in the correct order), yet when I build any Allegro project I get a crapload of "undefined reference" errors. And yes, I am including the proper headers. Honestly, I can live with bugged code completion and lack of code folding as long as I can make a project that will actually build properly.
I've been trying to ditch Dev-C++ in favour of Code::Blocks but I can't get it to freaking work. I've linked to everything properly, added all the linker and compiler options like the guide on the wiki said to do (and all in the correct order), yet when I build any Allegro project I get a crapload of "undefined reference" errors. And yes, I am including the proper headers. Honestly, I can live with bugged code completion and lack of code folding as long as I can make a project that will actually build properly.
Are you using the precompiled binaries? If so, just link like this(in case of doing dynamic linking)
{"name":"605409","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/f\/3f08402d94ee044151f88719bc49ec79.png","w":574,"h":293,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/f\/3f08402d94ee044151f88719bc49ec79"}
And you're good to go.
The monolith version links all relevant addons you'll probably need.
Just don't add the -lib prefix when adding manually to the linker options list and it should work fine.
Doesn't help. Same thing. I'm doing it static linked, does that make any difference? I can't stand doing dynamic linking.
Have you tried #define ALLEGRO_STATICLINK?
Yes.
The problem with static linking is that you have to manually link all the libraries used by all of your static libraries.
Add these to your linking options :
-ldumb -lFLAC -lvorbisfile -lvorbis PATH/TO/freetype.a -logg -lz -lgdiplus -luuid -lkernel32 -lwinmm -lpsapi -lopengl32 -lglu32 -luser32 -lcomdlg32 -lgdi32 -lshell32 -lole32 -ladvapi32 -lws2_32 -lshlwapi
Why is that necessary for Code::Blocks and not Dev-C++? Anyway, I don't seem to have freetype.a. If I can compile statically linked in Dev-C++ without it, why do I have to compile it with it in CB?
So far all I'm getting with CB is more headaches than Dev-C++ ever gave me. It's also giving me errors about not being able to find flac, zlip, vorbis, vorbisfile, ogg, or dumb.
If I can compile statically linked in Dev-C++ without it, why do I have to compile it with it in CB?
That's like complaining your brand new car doesn't have those little vent windows like the clapped out '72 Chevy you previously had.
You compile statically the same way whether you are using DevC++ or C::B or MSVC or whatever else. If you link statically, then you have to link to the windows libraries that allegro uses, as well as the addon dependencies.
My guess is that you were never compiling statically to begin with.
Re freetype.a - if you didn't compile allegro with the ttf font addon, then you don't need it. If you did, then you need to find the freetype library. Either rename it to libfreetype.a and put it in mingw/bin or use the full path to it.
Re missing libraries - it all depends on which libraries and which addons were used to build A5 with. If support for a particular addon wasn't compiled into allegro, then you don't need to link to it.
Best bet is to start over, download the binaries for A5.0.5, set your project's search directories for includes and link libraries and use the monolith library provided by A5.
I've started over about 5 times now. I am using 5.0.5, I have all the includes included, and I have compiled statically in the past with the same setup in Dev-C++. I've taken the resulting compiled program and ran it without any DLLs present in the program folder or the system folder on a separate system. It's statically linked. My guess is something else is going wrong here because all this extra work isn't getting me anywhere closer to the solution, when far less was required of me to get everything working in Dev-C++. I'm also using the monolith library.
It's also giving me errors about not being able to find flac, zlip, vorbis, vorbisfile, ogg, or dumb.
They are named differently in the binary distribution of allegro, with the same naming conventions as Allegro. So the list I gave you earlier is not accurate for working with the binary distribution of A5. If you had built it from source it would work, but you didn't, and if you're having this much trouble, I recommend you save that option for later.
If you followed this guide
(http://wiki.allegro.cc/index.php?title=Windows_Vista,_Code::Blocks_10.05_and_Allegro_5)
exactly, then everything should be working perfectly to static link with allegro 5 in C::B.
Ah, I see. No, I didn't compile it myself. I downloaded the binaries.
That wiki guide is what I started with in the beginning and that guide gets me all those undefined reference errors.
Then you haven't set your linker options correctly.
Menu->Project->Build Options->[Select build type]->Linker Settings->Link Libraries Tab->Add the libraries listed on the wiki
Make sure the libraries you add match the libraries that came with your binary distribution (depends on which release you downloaded).
Yes, it's all there. Just like the wiki. This is what I'm getting:
..\..\allegro-5.0.5-mingw-4.5.2\lib\liballegro-5.0.5-static-mt.a(d3d_disp.o):d3d_disp.cpp:(.eh_frame+0x12)||undefined reference to `__gxx_personality_v0'|
..\..\allegro-5.0.5-mingw-4.5.2\lib\liballegro_image-5.0.5-static-mt.a(gdiplus.o):gdiplus.cpp:(.eh_frame+0x12)||undefined reference to `__gxx_personality_v0'|
c:\mingw\lib\libstdc++.a(new_op.o):new_op.cc|| undefined reference to `_Unwind_SjLj_Register'|
c:\mingw\lib\libstdc++.a(new_op.o):new_op.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(new_op.o):new_op.cc|| undefined reference to `_Unwind_SjLj_Resume'|
c:\mingw\lib\libstdc++.a(eh_personality.o):eh_personality.cc|| undefined reference to `_Unwind_SjLj_Register'|
c:\mingw\lib\libstdc++.a(eh_personality.o):eh_personality.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(eh_personality.o):eh_personality.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(eh_personality.o):eh_personality.cc|| undefined reference to `_Unwind_SjLj_Resume'|
c:\mingw\lib\libstdc++.a(eh_personality.o):eh_personality.cc|| undefined reference to `_Unwind_SjLj_Register'|
c:\mingw\lib\libstdc++.a(eh_personality.o):eh_personality.cc|| undefined reference to `_Unwind_SjLj_Resume'|
c:\mingw\lib\libstdc++.a(eh_throw.o):eh_throw.cc|| undefined reference to `__w32_sharedptr_unexpected'|
c:\mingw\lib\libstdc++.a(eh_throw.o):eh_throw.cc|| undefined reference to `__w32_sharedptr_terminate'|
c:\mingw\lib\libstdc++.a(eh_throw.o):eh_throw.cc|| undefined reference to `_Unwind_SjLj_RaiseException'|
c:\mingw\lib\libstdc++.a(eh_throw.o):eh_throw.cc|| undefined reference to `_Unwind_SjLj_Resume_or_Rethrow'|
c:\mingw\lib\libstdc++.a(eh_alloc.o):eh_alloc.cc|| undefined reference to `_Unwind_SjLj_Register'|
c:\mingw\lib\libstdc++.a(eh_alloc.o):eh_alloc.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(eh_alloc.o):eh_alloc.cc|| undefined reference to `_Unwind_SjLj_Resume'|
c:\mingw\lib\libstdc++.a(eh_alloc.o):eh_alloc.cc|| undefined reference to `_Unwind_SjLj_Register'|
c:\mingw\lib\libstdc++.a(eh_alloc.o):eh_alloc.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(eh_alloc.o):eh_alloc.cc|| undefined reference to `_Unwind_SjLj_Resume'|
c:\mingw\lib\libstdc++.a(eh_terminate.o):eh_terminate.cc|| undefined reference to `_Unwind_SjLj_Register'|
c:\mingw\lib\libstdc++.a(eh_terminate.o):eh_terminate.cc|| undefined reference to `__w32_sharedptr_terminate'|
c:\mingw\lib\libstdc++.a(eh_terminate.o):eh_terminate.cc|| undefined reference to `__w32_sharedptr_unexpected'|
c:\mingw\lib\libstdc++.a(eh_terminate.o):eh_terminate.cc|| undefined reference to `__w32_sharedptr_terminate'|
c:\mingw\lib\libstdc++.a(eh_terminate.o):eh_terminate.cc|| undefined reference to `__w32_sharedptr_unexpected'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `__w32_sharedptr'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `_Unwind_SjLj_Register'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `__w32_sharedptr'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `_Unwind_SjLj_Resume'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `_Unwind_SjLj_Register'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `__w32_sharedptr'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `__w32_sharedptr'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `__w32_sharedptr'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `__w32_sharedptr'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `_Unwind_SjLj_Resume'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `__w32_sharedptr'|
c:\mingw\lib\libstdc++.a(eh_globals.o):eh_globals.cc|| undefined reference to `__w32_sharedptr'|
c:\mingw\lib\libstdc++.a(eh_catch.o):eh_catch.cc|| undefined reference to `_Unwind_SjLj_Register'|
c:\mingw\lib\libstdc++.a(eh_catch.o):eh_catch.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(eh_catch.o):eh_catch.cc|| undefined reference to `_Unwind_SjLj_Unregister'|
c:\mingw\lib\libstdc++.a(eh_catch.o):eh_catch.cc|| undefined reference to `_Unwind_SjLj_Resume'|
||=== Build finished: 46 errors, 0 warnings ===|
And I get the same thing if I use the individual libraries as opposed to the monolith.
Oh, that crap.
I think it's something to do with choosing between -md or -mt and linking with MinGW's C runtimes. Are you using the -md libraries? They should be dynamically linked with the c runtime.
OR, since it's talking about libstdc++.a, it might mean you have to link with -lgcc_eh.
I'm using the "static-mt" libraries, like the wiki says. And I have this in my linker options:
-lgcc_eh
-static-libgcc
-static-libstdc++
Again, like the wiki says. Should I try using the md's?
MT vs MD
These options affect how the compiler links to the standard C library. The MT version includes it as part of the executable. The MD version leaves it out, and requires you to also include the appropriate system DLLs when you distribute your program.
So -mt means the allegro libraries are already linked to MinGW's c runtime, so in that case, you don't need to link using -static-libgcc or -static-libstdc++ and you should let MinGW link to the c runtime dynamically in your program as well.
And -md means they weren't linked to the c runtime, so in that case you could do it either way.
Since you are using -mt I don't think the errors you are getting are due to the c runtime.
Which version of MinGW are you using? Does it match the version of Allegro you downloaded?
Those errors are from using a different version of gcc than the one used to compile Allegro. What does gcc -v say and what exact binary package did you download?
I have MinGW 4.6.1.
I realize that's not what the latest Allegro binaries were compiled for but I did what the wiki told me to and followed the instructions to install MinGW. I searched for a version of MinGW 4.5.2 everywhere but it's impossible to find. Do I have to go through the grueling process of compiling Allegro manually with 4.6.1? (something I also tried to do at one point and gave up in frustration)
I don't know, I haven't used 4.6.1 yet. It might work with the 4.5.x binaries but if that's what you're using I guess not. One other possibility with those errors is that you're compiling C code as C++ or vice versa.
Depending on which addons you need, compiling A5 from source isn't as bad as it sounds. The hard part is compiling things like Vorbis / Ogg, which you need MSYS for.
A5 itself :
cd allegro mkdir build cd build cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release .. mingw32-make mingw32-make install
Well then, until somebody compiles new binaries the current ones listed on the website are pretty useless as there are no previous versions of MinGW available anywhere that I can find.
I'd like to have every feature available in Allegro. I'll definitely be using Vorbis among other things so I'd have to compile it with everything, which is why I gave up previously. I've used MSys before but not CMake. And the instructions for building the source were very vague or outdated. Like most information on Allegro, it seems. Unfortunate, because it's such a great library.
And the instructions for building the source were very vague or outdated.
Can you point to anything specific with regards to building allegro itself? If there are problems, we'd like to fix them.
Just what's in the readme.txt. It's just really unhelpful. All it says is that you need to have CMake. Doesn't say how to use it or what commands to type in or anything. Unless I'm missing something.
Can you point to anything specific with regards to building allegro itself?
The problem is people expect the Allegro instructions to tell them how to use their operating system and tools, which is unrealistic. Instructions that say the following should be sufficient:
Here are the list of dependencies:
libpng (website)
libjpeg (website)
...
Here are some cmake options:
-DSHARED=off/on
-DCMAKE_BUILD_TYPE=Release/Debug
Install the dependencies that you want.
Install cmake.
Open a terminal at the location where you extracted Allegro's source
Create a build directory, change into it, and run cmake .. (See options listed above.)
Run the makefile or open up the generated project file, whichever is applicable.
Use pkg-config to link on Linux/OS X. On Windows, just link to the appropriate lib/a files that you are using.
See the API documentation for how to use Allegro.
If you cannot follow those instructions, then you should just read books like Surfing the Internet for Dummies, CMake for Dummies, Windows for Dummies, MSVC for Dummies, or Code::Blocks for Dummies until your knowledge is sufficient.
As I've said before, it's like buying a car and assuming the owner's manual explains how to drive.
If people want to write walkthrough tutorials on the wiki, then that is great. I have no objections. But of course it doesn't solve the actual problem of a person's incompetence since they are just copy/pasting things without learning what they are doing.
I feel this version [www.microsoft.com] is still better than 2010. Maybe the 2011 or 2012 version will have caught up, but I'd go with 2008 for now. The focus of the 2010 version was porting it to .NET. In that process, some things (like performance) were lost. Yay for Microsoft dogfooding .NET
Maybe you guys have moved past this already, but I just want to say I agree with torhu that VC++2008 is better than 2010. (VC++2010 is slow.)
In my personal opinion, the ranking of current IDEs is something like this:
VC++2010
Code::Blocks
To be honest, it's always been a puzzle to me why Code::Blocks is so popular on this forum. Last time I tried it, I thought it was painfully bad. That was probably a couple of years ago now - I expect it would have improved since then, but it would need to have improved a lot to get close to the top two on my list. And yet somehow whenever someone asks about IDEs, Code::Blocks always gets the most recommendations.
(By the way, I don't use Qt itself; I only use the IDE.)
In my personal opinion, the ranking of current IDEs is something like this:
MSVC 2010 plays nicer with the system DLLs (than 2008). But yeah, I've noticed that it is slower and seems to have less functionality. Probably par for the course.
I've been using Geany on Ubuntu as a code editor. So far I've got no complaints. I haven't actually tried it as an IDE yet.
Just what's in the readme.txt. It's just really unhelpful. All it says is that you need to have CMake. Doesn't say how to use it or what commands to type in or anything. Unless I'm missing something.
Take very careful what I'm going to tell you, I have used Allegro 5.0.4 with MinGW 4.6.1 with no problem, I don't know if these things could change from system to system, but I really doubt it. However, if you want to build Allegro, in the Wiki there is a tutorial explaining how to do it, it's about A5.1 but it's practically the same. I really don't recommend you to do it, you must be probably very tired/bored by now, so this could be even worse, the first thing you need to learn about this world is that you need a lot of patient. Think that the tutorial you're reading has been read by a lot of people, and just few of them have complaining about it, but none of them had a problem with MinGW 4.6.1, think that you would be the first one with this issue, so I know a lot of people have told you this, but you must be doing something wrong. I'm going to try it again on my computer later on, and tell you if I had any problem with M4.6.1 and A5.0.5
As I've said before, it's like buying a car and assuming the owner's manual explains how to drive.
Well it's true that people need to learn a little bit the tools they're going to be using, it's not only about C/C++ and Code::Blocks, you also need to know these tiny tools to compile libraries and other things. However, when you create something you want people learn how to use it, the more info you give them, the better. Telling to someone to install cmake, open it, configure and build Allegro and that's it, it is a lie.
There is a lot of trouble when building Allegro:
The little changes you need to do to the FLAC library.
Using the dynamic or static libraries of each dependency?
On Windows you need MYSY and not the normal console.
You don't need the entire distribution of directX.
OpenAL-soft, is not the same than OpenAL.
OpenAL-soft is not able to find the DirectX in the Deps folder so you need to put it inside the MinGW folder directly.
When building Allegro 5.1 I need to link in all my projects to "OpenAL.a" because the unique way I can compile it is dynamically with an import library.
So yhea, it's not as easy as the tiny and beauty README file says, but fortunately all the info is already on the web, if you know how to use the tools you can do it.
If people want to write walkthrough tutorials on the wiki, then that is great. I have no objections. But of course it doesn't solve the actual problem of a person's incompetence since they are just copy/pasting things without learning what they are doing.
It's not the same when you start driving a car for first time, without to even have seen someone driving it, than if some one tells you how to do it first and then is your turn, so I think that by seeing a walkthrough could make you understand a lot of things. Sometimes you need to see it in practice to get it.
It's true, the developer doesn't need to explain how to use the tools. However some developers do it, and I consider it as a "extra" point to them.
Edit: I have tried again with MinGW 4.6.1 and Allegro 5.0.4 (I thought I had 5.0.5) and it works fine...
Well then, until somebody compiles new binaries the current ones listed on the website are pretty useless as there are no previous versions of MinGW available anywhere that I can find.
You can download everything you need for MinGW 4.5.0 manually from Sourceforge. Go to the MinGW website and then click on downloads. See the instructions for manual installation here :
http://www.mingw.org/wiki/InstallationHOWTOforMinGW
And, since it works for AMCerasoli, there must be something else wrong.
I would try the static-md versions. They haven't been linked to the c runtime, and it may remove the errors you are getting. Also, you can try moving -lgcc_eh after the -static-libgcc and -static-libstdc++ options. gcc is pissy about the order you link in.
There definitely should be older versions of mingw at http://sourceforge.net/projects/mingw. If you search for them. Last time I checked they always kept all of the old versions around.
There are previous versions there but 4.5.2 is not among them.
Thanks for your help, everybody. I'll give it another try in the next few days. I'm not "tired/bored" with it, I was just a little frustrated with the lack of directions. And a specific version of MinGW.