Allegro build problem on windows 10
Mitch Randall

I am not able to get allegro 5.2.2 to build on windows 10 machines. I've tried two. I have been using allegro on other windows versions for years.

Here's what I did starting with two clean windows 10 machines.

Today's date: July 11, 2017
1) Installed MS DirectX SDK.
(I had to unistall MSVC++ back to 2010 because of error S1023 - a well documented issue)

2) Installed MinGW using mingw-get-setup
It installed:
mingw-developer-toolkit 2013072300
mingw32-base 2013072200
mingw32-gcc-g++ 5.3.0-3
msys-base 2013072300

3) Added c:\MinGW\bin;c:\MinGw\MSYS\1.0\bin;c:\MinGW\MSYS\1.0\local\bin to the user path. Tested that make and grep etc. were available from a cmd window.

4) Installed cmake latest version 3.8.2 (cmake-3.8.2-win64-x64.ins)

5) Got the latest allegro source Unzipped it to create c:\allegro

6) run cmake-gui
Where is the source code: C:/allegro
Where to build the binaries: C:/allegro
Click on Configure
Click on Generate

7) Then, in a command window, I cd\allegro and type make


With both computers (an ASUS running win10, and an HP running win10) I get a compile after about 20 source files compile:

[ 5%] Building C object CMakeFiles/allegro.dir/src/file_stdio.c.obj
c:/allegro/src/file_stdio.c: In function 'file_stdio_ferrmsg':
c:/allegro/src/file_stdio.c:302:7: error: unknown type name 'errno_t'
errno_t rc = strerror_s(userdata->errmsg, sizeof(userdata->errmsg),
make[2]: *** [CMakeFiles/allegro.dir/src/file_stdio.c.obj] Error 1
make[1]: *** [CMakeFiles/allegro.dir/all] Error 2
make: *** [all] Error 2

For fun, I went into CmakeCache.txt and changed

//Have function strerror_s


//Have function strerror_s

Then it was able to get past the compile of file_stdio.c

But then it had dozens of errors because

[ 13%] Building C object CMakeFiles/allegro.dir/src/win/whapxi.c.obj
In file included from c:/allegro/src/win/whapxi.c:67:0:
C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/Include/xinput.h:231:5: error: unknown type name '__in'
__in DWORD dwUserIndex, // Index of the gamer associated with the device
C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/Include/xinput.h:232:5: error: unknown type name '__out'
__out XINPUT_STATE* pState // Receives the current state
C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/Include/xinput.h:237:5: error: unknown type name '__in'
__in DWORD dwUserIndex, // Index of the gamer associated with the device

and on and on and on.......

Can anyone experienced with this recognize what is going on? What is wrong?



Where did you get MingW from? The versions seem to be a bit dated.
I'd recommend trying out MSYS2. I've written/updated the tutorial about it here.

(Btw., maybe someone with access to the Wiki might be so kind as to merge it.)

Edgar Reynaldo

You don't need MSYS2 for MinGW, and is outdated. They are stuck on gcc version 5 and have lots of other problems as well.

You can use my binaries for MinGW if you like. You can find them here :

All you need to do is unpack the archives, put them somewhere you like, add your mingw\bin folder to the path, and compile away.

My binaries come with all the dependencies prepackaged. No need to build anything yourself.

If you do want to build allegro yourself with mingw, you will have some problems. The DXSDK needs sal.h, which is provided on MinGW-w64 comes with a full set of direct x headers and libraries so the SDK is not needed.

Your problem with HAVE_STRERROR_S stems from being outdated. They don't have all the functions necessary, so you have to manually fiddle with things like you found out.

My recommendation is to use MinGW-W64, regardless of whether or not you build it yourself. Be aware that the compiler version has to match the version used to build allegro and its dependencies.


Would it be possible to write a batch script to automate the collection and building of Windows dependencies? I believe that an important role of free software is making it easy to build from source so that users of it can trust that there are no hidden instructions in their code (not that every user audits it, but if any user audits it, they can find it). I imagine with at least MSYS you must have enough tools at your disposal to automate the process of collecting dependencies. I'd be willing to try to put one together if somebody could lay out the steps required and work with me to work out the kinks.

Binaries are nice, but a text-based solution is always nicer in a free world. :)

Edgar Reynaldo

Writing a build script for Windows would be somewhat difficult I think, given my experience building all the dependencies. SiegeLord himself made cmake scripts to build each dependency, but that's not strictly necessary, as my binaries show. I built everything directly with either cmake or MSYS and autotools, using a mingw-w64 compiler. However, I did have to patch physfs and theora to get them to build properly. I don't know if the changes will ever make it upstream though.

Maybe next time a new version of Allegro comes out I will document the steps taken to build everything. It takes a decent while to do, but once the deps are built there's (usually) no reason to rebuild them ever again.

But I agree, building on Windows is in desperate need of some kind of automation. I would be willing to help you with this in my spare time if you want bamccaig.

A gmail account won't kill you. :/ Especially a fake temporary one. ;)


If you can note down each step I would be willing to attempt to script it. I lean towards batch only because I've spent a good deal of time learning it for Windows compatibility, but in this case I guess we'll always have (and depend) on at least parts of MinGW/MSYS so it might be best to use bash. Whatever. There should be no reason we can't automate every step of the process. We can patch dependencies as necessary using MinGW or MSYS patch(1). The only concern is the maintenance cost to keep it working as dependencies change. But having a starting point is always the first step. If we can't maintain it going forward then we'll have learned a few things and not much else, but if we can maintain it going forward then users that request build instructions can be shown the shell program we output: that will tell them everything need to do, and if they trust us they can just run it.

Edgar Reynaldo

I probably won't have any time to work on this until the weekend, and perhaps a few more days to get me caught up with the rest of my responsibilities.

Changing everything from a cmake-gui configuration that I use into a cmake command line config may be problematic, especially for allegro. There are a ton of things to configure and it might be hard to do in a single command line.

I suppose curl could be used to gather dependencies and place them into their own folder. Create a build folder and run cmake/configure.

If SiegeLord contributed his cmake scripts, it might go a long way towards accomplishing this.

Mitch Randall

This reply is specifically to Polybios:

I followed the "here" link in your above post to go to your installation tutorial.

I brought my machine to a clean state by removing cmake, mingw, and the allegro source.

Your instructions worked flawlessly up to number 5. I installed MSYS2, ran all of the pacman commands, etc. it was flawless.

At number III) B) 5) is where it is time to run cmake and then compile the allegro library. (Remember, I have been building and using allegro since the 90's on DOS and windows platforms). Here's what happens:

test@DESKTOP-NUKJ96A MINGW64 /c/build
$ cmake G"MSYS Makefiles" -D"CMAKE_SYSTEM_PREFIX_PATH:PATH=/mingw64/x86_64-w64-mingw32" -DWANT_MONOLITH=on ../allegro
-- Building for: NMake Makefiles
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:17 (project):


is not a full path and was not found in the PATH.

To use the NMake generator with Visual C++, cmake must be run from a shell
that can use the compiler cl from the command line. This environment is
unable to invoke the cl compiler. To fix this problem, run cmake from the
Visual Studio Command Prompt (vcvarsall.bat).

Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.

CMake Error at CMakeLists.txt:17 (proj..... (there is another page of error description)

Polybios: Your tutorial was flawless, well written, and easy. I now have the 64 bit and newer version of MSYS2, and a 64 bit MinGW. But at that step III) B) 5), something went afoul. Cmake doesn't seem able to find the compiler within the environment.

If I type gcc, make, grep, cmake,... it all runs from the msys shell, so I know that the path environment is set up okay.

The computer I am using is literally right out of the box. The only thing I did to it was install DirectX and then attempt to get allegro working.

Thanks for your help so far, and thanks in advance for any help you can give. As I say, I compiled allegro 5.2.2 on my windows 7 machine. I just can't get it to compile on either of two brand new win10 machines.

Peter Hull

Did you actually put

cmake G"MSYS Makefiles" ...



cmake -G"MSYS Makefiles" ...

because if it's looking for NMake and cl, that's Visual C++ stuff.


I had a try myself (Windows 10, 64-bit). Following the instructions on the wiki I was able to build Allegro and run the examples. I didn't try anything more ambitious than that, though.

These days I mostly use Linux; if I'm on Windows I use Visual Studio and the NuGets.

I got MSYS2 from , not what the wiki says. Apart from that I followed the instructions.

Mitch Randall

Peter and Polybios,

Thank you Peter for the catch!

I MISSED THE '-' in front of the G!!!!

Now allegro built perfectly!

Thank you Polybios for the step-by-step installation guide. I can vouch that it works perfectly.

I recommend anyone attempting to get allegro on a new machine to follow Polybios' link above.

Neil Roy

I decided to give it a go and try to compile Allegro again for myself. Not surprisingly, following the wiki instructions leads to a problem.

Following all instructions to the letter, I get this when I try the cmake part.

cmake -G"MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=/mingw64/x86_64-w64-mingw32 -DWANT_MONOLITH=on ..

CMake Error: Could not create named generator MSYS Makefiles

  Unix Makefiles               = Generates standard UNIX makefiles.
  Ninja                        = Generates files.
  CodeBlocks - Ninja           = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - Ninja             = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
  KDevelop3                    = Generates KDevelop 3 project files.
  KDevelop3 - Unix Makefiles   = Generates KDevelop 3 project files.
  Kate - Ninja                 = Generates Kate project files.
  Kate - Unix Makefiles        = Generates Kate project files.
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files.

Edgar Reynaldo

You can use "Unix Makefiles" or "MinGW Makefiles", depending on which environment you're using. Type cmake -h at the command line to see a list of available generators on your platform.


Glad that it worked, Mitch.

Neil Roy said:

Not surprisingly, following the wiki instructions leads to a problem.

Well, that's exactly why I updated the article in the thread referenced above. Unfortunately, I couldn't edit the wiki at the time and still can't.

A gmail account won't kill you. :/ Especially a fake temporary one.

Not gonna happen, sorry.

Edgar Reynaldo

So it's okay for us to sell our souls to Google and edit the wiki for you, but it's not okay for you. That's cool. 8-)

Neil Roy
Polybios said:

Well, that's exactly why I updated the article in the thread referenced above. Unfortunately, I couldn't edit the wiki at the time and still can't.

I'll check that out. I followed a reference already, didn't see a second one. If I ever get this sucker compiled I am awarding myself with something. ;)

Edit: Nevermind, just noticed the "compile it yourself" part, ;D, that's what happens whan I go to the bathroom between reading... gonna try that now.

Remove the MSYS2-supplied package if installed 

>:( Making me do extra work!

Edit2: Compiling now. Never really used MSYS before, starting to wish I had. Nice system. The following advice you give makes me nervous...

"When you want to run programs build with MSYS2 outside your terminal window, your system needs to be able to find the DLLs that reside in /mingw64/bin (for a 64 bit installation). So you'll need to add C:\msys64\mingw64\bin to your system PATH if C:\msys64 is where you installed msys2. You should take care that no other similar installation is on the path before this one. "

...I don't think it is a good idea to have DLLs in your path. Not when developing anyhow. It leads to problems like what Edgar had, when you compile something that is static, but accidentally require a DLL. You won't catch that problem if your DLLs are in your path. I purposely leave all my DLLs out of my path for projects I am developing for, this way if I need a DLL, I will know if I did not include it with the binary, or if it is static, I will know if it needs a DLL. Instead I copy the DLLs needed into the same folder as my executable. This is good as once it works, I know what DLLs to include etc... I just include everything in that folder.

There should at least be a warning about this if you ever intend to add this to the WIKI as it can be a hard to spot gotcha.


You can always open a console window and reset the PATH variable to a base setting to test if your executables are linking to any unexpected libraries:

set PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem

That is apparently Windows 7's default PATH, but you can Google to find the right setting for your exact OS. Or you can backup the PATH you have now into a separate variable MY_OLD_PATH or something. Restore the path for a console window and try to run your game.

Note: Setting the variable in a console only affects that console and new child processes. To have a variable persist forever you need to edit it in the registry or use the environment variable GUI.

Having DLLs in the PATH is a necessary evil in Windows to have the convenience to use the command line without having to type paths or cd all the time. It defeats the purpose entirely if you can't just type "command arg..."

Edgar Reynaldo

From a command console, enter a new session by typing cmd. Then type 'set path='. This will remove the path variable entirely from the session. Then cd to your game's folder and run it. That will make sure it is using strictly the directory it is in to look for dlls. When you're done, just 'exit' the session and you'll be restored to your regular environment. Voila. ;)

If building with MSYS2 means you depend on dlls from the mingw\bin folder, there's something wrong. All you should need is the c and c++ std libraries unless you linked those statically too.


Let's try to clear a few things up a bit.

First, you'll always have to have some DLLs on the path if you want to run your binaries "normally" outside your IDE, won't you? Unless you build everything statically.

Second, MSYS2 is package management for Windows. Every library package you install through MSYS2's pacman will contain shared libraries, likely depending on other shared libraries from other packages.
This is by design and it's probably the only way to sanely implement such a system. So if you install libraries through pacman, there will be DLLs.
However, the compilers work just normally, so binaries produced with the usual -static... options will not depend on anything unusual or msys2-specific. So it's absolutely fine to use it for building.[1].
But: If you want to limit the DLL dependencies of your Allegro DLLs, you have to build all the Allegro dependencies yourself, the versions from MSYS2-packages won't do.[2]

Well not quite: Fear not, the great SiegeLord has made the allegro_winpkg project: The dependencies are bundled together in one repository and ready to be turned into static libraries by the scripts accompanying them. There are also scripts to build several flavors of Allegro binaries themselves.[3], using exactly these statically built dependencies. You can also download ready-made versions of Allegro and/or dependencies' static libraries for MSYS2 from (i.e. the results of using allegro_winpkg). However, MSYS compiler versions increase more quickly than Allegro versions, so these might not always be compatible.

Now, what to use?
My personal opinion is the following: For getting into Allegro5 development on Windows, using MSYS2-presupplied packages (they do provide Allegro5 themselves) is probably easiest (if MSVC + Nuget packages are not an option). For anything else, especially distribution (if you ever get there), compile your own binaries from allegro_winpkg, at least use it to compile static libs of the dependencies and then compile Allegro5 yourself with these.

One last thing: "This was all easier with A4"? Not quite. Most of the complications arise from the dependencies for addons for which A4 had no equivalent functionality (ttf fonts, video, mod files, jpeg/png loading, audio codecs, native dialogs, ...). Everyone is free to build Allegro5 without these addons and it will result in less hassle, but also less functionality.


  1. There's a difference between mingw-w64- and MSYS2 toolchains. The latter will produce binaries that need msys-2.0.dll
  2. You could try to remove all dll.a files, because they do seem to ship some static libraries, but it doesn't seem to work reliably.
  3. See
Edgar Reynaldo

You left out a few things. win_pkg uses older versions of the dependencies, and SiegeLord said it would be somewhat difficult to update them. My binaries include ALL static versions of the dependencies. It would be FAR easier to use my binaries then build allegro yourself. And MSYS2 is not necessary, and introduces further dependencies on the MSYS2 runtime itself. You can build directly with MinGW-w64 with absolutely no need of MSYS2. Sometimes you need MSYS to run configure because they didn't ship cmake scripts but whatever. If you build all the libraries yourself you don't have these problems, which is what I did. ;) ;) ;)

Also, I would be very surprised if msys2's repository includes a version of allegro 5 that is actually RECENT.


They have That's quite good. ;)
There is no additional dependency on the MSYS2 runtime.

It's just convenient to use MSYS2 because it gives you all the standard Unix tools if you want them. Of course you don't have to.
Everyone appreciates your efforts, people are free to use whatever they want.

Personally, I'd rather use an official compiler, though.

Neil Roy

I'll stick to Edgar's builds, thanks. He does a nice job. Figuring out all the ins and outs of building this is just not my thing and quite frankly, turns me off of programming entirely.

This does illustrate the problems with this version of Allegro 5, as much as I like it, and I DO like it, it's awesome! It's just a maze of ridiculous hoops to jump through to compile it yourself. I'm happy to help Edgar locate problems with his builds and get them working, seems like a better use of my time. ;)

Nice work Edgar, this only gives me more respect for your talents.

Edgar Reynaldo

Thanks for the kind words Neil. I'm happy to provide these as a way of giving back for all the things allegro has done for me. :)

Mitch Randall

This is an update (sadly)....

I thought I was out of the water when allegro compiled following Polybios' step-by-step tutorial near the top of this thread. But....

I was unable to run programs because some entry point or something was wrong....

Not satisfied, I wasted two days figuring out what my problem really was. After all, I just compiled the allegro source on a win7 machine a few days ago flawlessly, here is the answer to my own question: How to install allegro 5.2.2 on a brand new, clean win10 machine:

1) Uninstall any MSVC++ redistributable back to before version 2010. (This prevents error s1023 - a well documented error with step 2)

2) Install DirectX from microsoft's official site.

3) Install mingw (mingw-get-setup.exe) from the site. This is the older 32 bit version, but this is what worked for me. Install Choose everything but ada, objectivec, and fortran from the "basic setup" tab.

3.5) Add c:\mingw\bin and c:\mingw\msys\1.0\bin to the local system path by going to windows "system" (in control panel) and then clicking on "advanced settings" then clicking on "environment variables". This will keep the path any time you open a cmd window.

4) Install cmake (cmake-3.8.2-win64-x64.msi)

5) Get from . Unzip it into c:\ so that you end up with an allegro directory in the root c drive.

6) Also pull down sal.h at the bottom of the page. Put it in C:\MinGW\include. It turns out this is the file I was missing all along that allows allegro source to compile with DirectX, which is required.

7) Run cmake-gui.
a) Where is the source code: C:\allegro
b) Where to build the binaries: C:\allegro
c) Click on Configure - it makes a bunch of red statements
d) Change WANT MONOLITH to have a checkmark
e) Click on Configure again. All of the red should go away.
f) Click on Generate
g) exit Cmake.

7) Now edit into C:\allegro\cmakecache.txt
a) search on strerror_s
b) change to read:
//Have function strerror_r
//Have function strerror_s

This solves the problem that kills the compile at about 4% into it.
I think this is something that needs to be fixed, because after I run cmake, these values are set to 1, but then during compile there is an error because strerror is undefined. So something about the Cmake function that determines if strerror is defined is wrong.

8) in a dos cmd window, go to c:\allegro and type:

9) type
make install

10) Finally, I added c:\allegro\lib into my local path environment variable so that I can run programs from any directory without worrying about the monolith .dll file.

So, in conclusion, the old mingw is perfectly adequate to compile the allegro5 source code, but there are two issues:
1) sal.h must be moved into the mingw\include directory, and
2) you have to fool the system into knowing that strerror is NOT defined.

Note also that there are numerous threads from the past that discuss the old problem that sal.h is needed to compile and resolve DirectX __in and __out missing items. And there are also threads about the known problem of the strerror_s!!!!

I hope this helps people in the future who just want to get their old, familiar allegro up and running on a win10 machine!!!

Thanks to everyone for all your great support and help. I love allegro, and I love the great community of people that have put so much into this!!!!!!

Thanks everybody for the help.


You don't happen to still have the exact error message, do you? Do you remember if you also got it when running programs inside the msys terminal?

Edgar Reynaldo


I told you you would have problems if you used old mingw and the DXSDK. Do NOT uninstall your MSVC runtimes. Programs will stop working. The DXSDK from Jun 2010 works if you use sal.h from But it's a MASSIVE download, and the most recent version of DX now comes with the Windows SDK, which is even more massive. mingw claims to have POSIX support, but it's spotty at best, and there are unimplemented standard functions and structs, which is unacceptable if you want to live in the real world and use a modern version of C or C++.

I've done the exact same thing as you to get my binaries to build in the past.

That is the EXACT reason I said to use MinGW-W64. They provide binary distributions of their compiler that you can just plop into place and compile with. They COME with DX headers, libs, and work perfectly with the DirectX 9, 10, and 11 runtimes that people have installed on their computers.

See for downloads (scroll down to the links).

PLUS, the most recent version of gcc supported by vanilla is 5.3. That is ANCIENT. It can't even properly compile (much less support) C++11. The version of the compiler that I used is made for gcc version 7.1, and 8 will be out in the near future. Full support for C++11,14,17 etc...

See for details.

Neil Roy
bamccaig said:

Having DLLs in the PATH is a necessary evil in Windows to have the convenience to use the command line without having to type paths or cd all the time. It defeats the purpose entirely if you can't just type "command arg..."

For the developer, no. As a developer you do not want the DLLs for your project in your path. DLLs for allegro or whatever library you are programming for should not be in your path. The reason is that if you statically link a project but somehow forget and accidentally link to a DLL that ends up being required for your project, than you won't see this problem until someone reports back to you that your work doesn't work on their machine... because you linked to a DLL you should not have or you forgot a DLL that was needed; because you had them in your path so the problem never shows up. Just ask Edgar (no offence to him intended) about the last Allegro build of his. He had the DLLs in his path so he missed the fact that he linked against DLLs for the static version of Allegro. This made it more difficult to spot what the problem was when it worked for him but not for me. In those cases one starts to think it is obviously something the end user done wrong as it works for you.

These days, with so much disk space, there is no need to have DLLs in your path anymore (or have them at all, just statically link) as it leads to these sorts of problems. But at the very least, as a developer, you should not have the DLLs for the libraries you are working with in your path so you can easily spot problems as I already described. I never have SDL or Allegro or anything like that in my path and you will find that all modern programs don't put DLLs in your path either! Look at games you installed, did they put things like SDL in your path or do you find the DLLs in their own folder? Putting them in your path is from Windows 95, 98, maybe XP days.

Edgar Reynaldo

You have to have entries in your path, at least for your system folders, and anything else you want to run. But you should keep custom (not system) dlls outside those folders and temporarily modify the path in a separate environment specifically for testing and running your app, unless you just keep all your dlls in the same folder as your program, which is what you should do.

Neil Roy

That's what I do. My DLLs are all in one folder, and I move the ones I need to run the game into the folder the game is in to test it. When I set up my game to install, IF it has DLLs (I normally statically link, so not a problem), they get installed along with the game in the same folder. But to develop the game with DLLs in the path? No way. I need to know if I am missing a DLL or if my game is trying to load one, and I won't get that if they are in the path.

Mitch Randall

Well, at least I got my allegro to compile and then run the examples. I can compile all my stuff and everything works.

I agree I should upgrade to the newest version of msys and mingw.

Right now, I can't say that your (Polybios) tutorial works, because when I was finished, programs wouldn't run. I suspect there was a dll missing, but it wasn't the allegro monolith.

When I would try to run one of the allegro examples from the msys shell, nothing would happen. It's as if I just hit return without typing the program name (ex_bitmap, for instance). I moved the monolith to the examples directory, and still something was missing. (As I said, the OS complained that an entry point was missing. If I ever recreate the issue, I'll publish the exact message verbatim.)

For now, I just needed to be able to compile so I can get my work done.

Thanks so much for the discussion. I really appreciate this community. I have gotten a lot out of it for many years.

For example, I wrote the the Doppler weather radar display that is in the DOW storm chaser trucks with allegro in the 90's. It's been on TV (many a news channel and Discover), and has served science for two decades.

Neil Roy

For testing the examples, just hop on over to regular Windows, navigate to the folder they are in and double click them.

Tyler Wrobel

You should make a website specifically build allegro oriented.

Thread #616969. Printed from