Allegro.cc - Online Community

Allegro.cc Forums » Installation, Setup & Configuration » Can't start Allegro application after build

Credits go to bamccaig, Chris Katko, and Edgar Reynaldo for helping out!
This thread is locked; no one can reply to it. rss feed Print
Can't start Allegro application after build
Laszlo Heim
Member #16,191
February 2016

Hi Everyone!

I followed the instructions at the official wiki to get started with allegro.cc (Windows, Code::Blocks and Allegro 5). I chose the dynamic linking, because I usually prefer dynamic linking.
I think I did everything right, and the compiler built the project successfully. However, when I run my application, I get an error (see attached picture). The application is a simple program for testing initialization:

#SelectExpand
1#include <iostream> 2#include "allegro5/allegro.h" 3 4int main(int argc, char* argv[]) 5{ 6 if (!al_init()) 7 { 8 std::cout << "Error initializing allegro!\n"; 9 } 10 else 11 { 12 std::cout << "Allegro initialized successfully!\n"; 13 } 14 15 return 0; 16}

I tried this also, but nothing.

I do not know what I did wrong, but I will try to link statically, and update the post.

:-/

Thank you for any advance,
Lasoloz.

Update - here I my specs:
Windows 10 64bit
Code::Blocks 13.12 with MinGW 4.7.1
allegro-5.0.10-mingw-4.7.0

I also downloaded MinGW version 4.8.1, and I made a new compiler profile with new toolchain executables. After this I created a new Project with the new compiler and the new libraries: same error. After copying the libstdc++-6.dll (this question) I get segmentation fault.

Chris Katko
Member #1,881
January 2002
avatar

Sounds like you're compiling with a different version than you're linking with.

Though, a StackOverflow post says:

http://stackoverflow.com/questions/7262362/mingw-the-procedure-entry-point-libiconv-could-not-be-located

Quote:

Make sure you have C:\MinGW\bin in your path before any other directory that contains libiconv-2.dll. Apparently the as.exe in some MinGW distributions are dependent on that DLL, and having an older version of it in the path somewhere (for example GnuWin32 tools) will cause as.exe to pick up the older version that doesn't have the entry point it's looking for.

So it could be load-order related. So in PATH, make sure MinGW is first AND restart your computer to ensure the changes apply globally.

ALSO, if you have multiple copies of that DLL and the wrong one gets found first, that's what gets loaded. That happened to a different MinGW user.

[edit]

This post had a clever idea. I didn't realize Windows has a where command.

Open up command and type

where allegro-5.0.10-md.dll

where, by default, only searches the PATH locations.

If it lists multiple (or NONE) you've either got multiple versions, or it may not be in the path.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Laszlo Heim
Member #16,191
February 2016

I don't know. I have the default MinGW compiler what I have downloaded with Code::Blocks and I also have a compiler on the "C" drive. This is the first time I get this error (I have built a lot of SDL projects) and I have the Code::Block's compiler chosen in properties.
Also, I set up a statically linked version of the program, but I can't compile. When I use the "-static-libstdc++" command it says unrecognized command, when I don't use it wants the "__gxx_personality_v0".
So, if I have problems with compiler setup, what should I do?

(There are some pictures about my configuration for reference)
{"name":"610190","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/7\/b77b01feba2603f384b4d010a9adfd49.png","w":757,"h":575,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/7\/b77b01feba2603f384b4d010a9adfd49"}610190
{"name":"610191","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/2\/0230c3312a296423081e16d12ac2ac06.png","w":1041,"h":727,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/2\/0230c3312a296423081e16d12ac2ac06"}610191

EDIT:
I deleted the second MinGW compiler, still nothing.

EDIT2:
I looked up for the dlls with where. Nothing, they are not present in any path variables, however I have old, dumped projects containing it.
The truth is, I don't really know the use of these path variables. ???

bamccaig
Member #7,536
July 2006
avatar

I think I did everything right, and the compiler built the project successfully. However, when I run my application, I get an error (see attached picture).

{"name":"610189","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/8\/e8d5c1bc23fbb44c6163b8bb9fd8643c.png","w":487,"h":183,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/8\/e8d5c1bc23fbb44c6163b8bb9fd8643c"}610189

FTFY.

I don't recognize that error, but from the sounds of things its related to exception handling. Though Allegro 5 is a C-based public API, they have resorted to using a little bit of C++ internally. Make sure your project is configured to build with g++ instead of gcc and see if that helps.

Laszlo Heim
Member #16,191
February 2016

I have g++ set as c++ default compiler. See the second post's image.

bamccaig
Member #7,536
July 2006
avatar

I would actually guess that Allegro should have been linked to the C++ runtime anyway and magically work, even if yours happened to be a pure C project... I'm just guessing... I installed Code::Blocks in Debian to take a peek (been years since I've seen it, let alone used it). I found it odd that it didn't differentiate between a C and C++ project. I can't seem to specify either. I don't know... :-/ I'm surprised it's building at all... Usually run-time just means the dynamic linker can't find something, but usually it's a library, not a symbol within a library... The linker should have caught that during the build process... :-/

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

You're mixing versions of MinGW. Your binaries from allegro.cc/files are built with a different version of MinGW than comes with CodeBlocks :

Quote:

NOTE: The codeblocks-16.01mingw-setup.exe file includes additionally the GCC/G++ compiler and GDB debugger from TDM-GCC (version 4.9.2, 32 bit, SJLJ). The codeblocks-16.01mingw_fortran-setup.exe file includes additionally to that the GFortran compiler (TDM-GCC)

I offer Binaries for MinGW 4.8.1 and Allegro 5.1.X at the following two links if you're interested :

https://sourceforge.net/projects/unofficialmingw/

https://sourceforge.net/projects/unofficialallegro5distribution/

Chris Katko
Member #1,881
January 2002
avatar

Yeah, that's what I thought, a version mismatch.

One other thing though:

I'm not a MinGW user, but does this picture imply Allegro is being linked before the core MinGW libraries?

{"name":"0230c3312a296423081e16d12ac2ac06-1024.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/7\/37c7994b120f1b5200a2c98f034cd760.jpg","w":1024,"h":715,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/7\/37c7994b120f1b5200a2c98f034cd760"}0230c3312a296423081e16d12ac2ac06-1024.jpg

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Laszlo Heim
Member #16,191
February 2016

I followed this wiki page configuring Allegro. There is a picture, where MinGW libraries are linked after Allegro. The compiler does not throw any errors, so I guess, the linking order is good :-/ . The compiler/library mismatch can be an error, I will try to do something with it, as you said.
Currently I'm on linux, but I will update this post after testing.

UPDATE:
I tried with MinGW 4.8.1 from that unofficial build. I get type errors within the io.h.
Next I tried allegro-5.0.10-mingw-4.5.0 library with MinGW 4.5.4 - reference error to al_install_system. So what's next? I think I will get back to SDL, because this Allegro seems to be hard.

(I also updated the question with my specs)

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

I tried with MinGW 4.8.1 from that unofficial build. I get type errors within the io.h.
Next I tried allegro-5.0.10-mingw-4.5.0 library with MinGW 4.5.4 - reference error to al_install_system. So what's next? I think I will get back to SDL, because this Allegro seems to be hard.

(I also updated the question with my specs)

Don't give up on allegro. It's a really good library. You're just not used to setting things up right yet.

If you use MinGW 4.8.1 then you need to use allegro binaries built with MinGW 4.8.1 as well. That's why the 4.5.0 and 4.7.0 binaries don't work (and no, 4.7.0 won't work with 4.7.1 either). You can't mix versions like that. At the second link I gave you I have binaries for Allegro 5.1.13 built with MinGW 4.8.1. Allegro 5.1 has far more features and bug fixes than 5.0 does. You should use 5.1 if possible. If they make a new stable release for 5.0 I will make binaries for it, but I put my personal endorsement on 5.1.

Laszlo Heim
Member #16,191
February 2016

OK. I will try to start everything from scratch. I will tell you if it works, but until Monday I can't test it. ::)

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

bamccaig
Member #7,536
July 2006
avatar

I will tell you if it works, but until Monday I can't test it. ::)

It is still Sunday in Romania. ::)

Currently I'm on linux, but I will update this post after testing.

Either I haven't been paying attention or you never said why you're working with Allegro in Windows. Are you just trying to make a Windows build because it's a popular platform? Or is there some other reason you aren't working with Allegro in Linux? It's generally much easier in Linux. :P

Laszlo Heim
Member #16,191
February 2016

So, I tried to use the that unofficial mingw release, but it does not work: it gives off64_t type error. I also downloaded the mingw version 4.7.0 to try it, but still nothing (just error: undefined reference to al_install_system), and I'm not messing with versions. :'(

There are more infos about the configuration in images.

Answer for bamccaig:
1) Yes, I never said why I'm working on Windows with Allegro.cc, but you guessed it. I want to see that works on Windows, and after that can come Linux. Today, it's much easier to sell (not just selling, but free-to-play with paying possibilities) games. Okay, the time for this is very soon, because I never made a really complete game, but I think it's good to plan ahead. And I want to build for Linux too, but first Windows.

2) I forgot about some extra classes, so I didn't have time to do this Yesterday (Monday).

bamccaig
Member #7,536
July 2006
avatar

My advice is rest assured Allegro is Windows compatible and works just fine. Windows is always a nightmare to setup builds though... If you feel yourself getting fed up then put the Windows build on hold and switch to Linux to just get some programming done! Allegro itself is mostly platform independent so you won't have to worry about incompatibility with Windows if you don't use platform specifics yourself. Once you have something that you actually want to release then you can worry about getting a Windows build made (you can also recruit help from the community if necessary).

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

So, I tried to use the that unofficial mingw release, but it does not work: it gives off64_t type error.

Post the code that you're using. Post a minimal example that gives that error. What are the steps that you took to reproduce it? I compile with that MinGW version all the time and it never gives me any errors. And I've used the Allegro binaries I built with it just fine as well. Are you including windows.h? Or some other conflicting headers? If you change the include order it may help.

Laszlo Heim
Member #16,191
February 2016

OK, I tried on Linux. No errors! I used the same program, and it worked. ;D So, should I build my own Allegro version from source on Windows too? ??? It is harder than on Linux? (I mean, here I just used make commands, but on Windows I need to link a lot of libraries to Code::Blocks)

bamccaig
Member #7,536
July 2006
avatar

First you need to build a bunch of libraries on Windows. There's no package manager full of binaries for the dependencies. It is a real pain in the ass... Several people have done it so they'd know better, but it's nothing like in Linux.

Maybe it would help if you started from scratch in Windows. Uninstall Allegro, uninstall Code::Blocks, uninstall MinGW. Start over. Make sure you install a matching Allegro for the MinGW that you install (with or without Code::Blocks)... :-/

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Are you using the -std=c++11 flag anywhere? I read in another thread that was causing problems.

There's a discussion of your problem here :
https://sourceforge.net/p/mingw/bugs/2024/?page=0

I think the key is not to use anything that causes ANSI code checks.

And btw, you don't have to build any of those other libraries, because I've already built all the dependencies for you in my Allegro binary package.

Laszlo Heim
Member #16,191
February 2016

Hey! :D The -std=c++11 flag was the problem! It compiled and it worked without any error!

Thank you very much,
H. L.

Battyhal
Member #15,775
October 2014

Hi!

Just to say that i had the same problem with Code::Blocks 16.x and Allegro 5.0.10-MinGW 4.7 in a new computer. I have fix it in one minute with the Binaries for MinGW 4.8.1 and Allegro 5.1.X from Edgar Reynaldo. I have to mention that i needed to copy-pasted the dlls from bin directory in SysWOW64 and it works!.

Thanks vey very much Edgar !!.

Go to: