Allegro.cc - Online Community

Allegro.cc Forums » Installation, Setup & Configuration » HOW TO INSTALL ALLEGRO5

This thread is locked; no one can reply to it. rss feed Print
 1   2 
HOW TO INSTALL ALLEGRO5
sunil kumar
Member #13,906
January 2012

I have allegro5 library i want to install it in dev cpp 4.9.9.2 but i unabled.plz can anybody help me

Dario ff
Member #10,065
August 2008
avatar

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

TranslatorHack 2010, a human translation chain in a.cc.
My games: [GiftCraft] - [Blocky Rhythm[SH2011]] - [Elven Revolution] - [Dune Smasher!]

simast
Member #12,668
March 2011

Better yet, skip Dev-C++, skip Code::Blocks and use free Visual C++ 2010 Express.

torhu
Member #2,727
September 2002
avatar

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 :P

Dario ff
Member #10,065
August 2008
avatar

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

TranslatorHack 2010, a human translation chain in a.cc.
My games: [GiftCraft] - [Blocky Rhythm[SH2011]] - [Elven Revolution] - [Dune Smasher!]

simast
Member #12,668
March 2011

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

MusiclyInspired
Member #13,895
January 2012
avatar

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.

Dario ff
Member #10,065
August 2008
avatar

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"}605409

And you're good to go. :P 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.

TranslatorHack 2010, a human translation chain in a.cc.
My games: [GiftCraft] - [Blocky Rhythm[SH2011]] - [Elven Revolution] - [Dune Smasher!]

MusiclyInspired
Member #13,895
January 2012
avatar

Doesn't help. Same thing. I'm doing it static linked, does that make any difference? I can't stand doing dynamic linking.

simast
Member #12,668
March 2011

Have you tried #define ALLEGRO_STATICLINK?

MusiclyInspired
Member #13,895
January 2012
avatar

Yes.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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

MusiclyInspired
Member #13,895
January 2012
avatar

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.

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.

They all watch too much MSNBC... they get ideas.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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.

MusiclyInspired
Member #13,895
January 2012
avatar

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.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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.

MusiclyInspired
Member #13,895
January 2012
avatar

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.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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

MusiclyInspired
Member #13,895
January 2012
avatar

Yes, it's all there. Just like the wiki. This is what I'm getting:

Quote:

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

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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.

MusiclyInspired
Member #13,895
January 2012
avatar

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?

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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?

Trent Gamblin
Member #261
April 2000
avatar

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?

MusiclyInspired
Member #13,895
January 2012
avatar

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)

 1   2 


Go to: