Building Allegro 5 from source code on Windows with MinGW
Last update : 10/13/2019
This section will go over the basic requirements of building Allegro 5. There are quite a few optional dependencies that you would probably like to have support for compiled in. Don't worry, we'll get to that. First the build tools, and then second, the dependencies, and third, allegro.
Before that, here are a few downloads made available for your convenience :
32 or 64 bit MinGW-W64 compiler (latest available here)
MinGW-W64-GCC81_i686_Posix_Dwarf.7z (32 bit MinGW compiler)
MinGW-W64-GCC81_x86_64_Posix_SEH.7z (64 bit MinGW compiler)
Dependency Source Package :
The source package includes the following libraries source code prepared for you. These are the latest releases as of 02/26/2019 : (an a following the version indicates I had to modify it slightly)
- Allegro 4.4.3
- Allegro 5.2.5
- Enet 1.3.14a
- FLAC 1.3.2
- Freetype 2.9
- libGIF 5.1.4
- libDUMB Kode54 2.0.3
- libJpegTurbo 2.0.2
- libOgg 1.3.3
- libTheora 1.1.1a
- libVorbis 1.3.6
- libPNG 1.6.36
- libZLIB 1.2.11
- OpenAL soft 1.19.1
- libOpus 1.3
- libOpusFile 0.9
- PhysFS 3.0.1
- libTIFF 4.0.10
- libWebP 1.0.2
CHM script (kindly donated by ArekXV) :
Some of the archives come in 7z or tar.gz format. The 7-zip archiver handles these files neatly. Download and install from here :
First you need a working build of MinGW. The MinGW-W64 project provides up to date, working, active versions of the latest gcc built for windows. You can get 32 or 64 bit compilers, but for portability I still recommend 32 bit, so you can share with a larger majority of your users.
On the Sourceforge download page, you can find the latest versions of MinGW-W64. Scroll down to see the release builds. Building Allegro 5 has been tested with MinGW-W64 GCC versions 7.1, 7.2, and 8.1.
Download the archive for your selected compiler version and architecture. Extract the contents of the folder and move the resulting mingw32 folder to c:\mingw.
To build several of the dependency libraries, we need to use MSYS 1.0.11 to use the autotools builds.
Instructions for installing MSYS 1.0 can be found here. You need to install MSYS 1.0.11, the MSYS DTK, and then extract the MSYS Core over the top of your new installation. Install to the default location, which is C:\msys. I put together an archive containing all the files you need to install MSYS 1.0.11. Find it here :
Next, run your new msys.bat file in your new c:/msys/1.0 folder to launch the MSYS shell. Verify you have a working installation and the path is set correctly. By default, msys will add c:\mingw\bin to its path. At the terminal, type
It should output the version of gcc you are using. If so, you're good to go.
You can get the latest cmake on the Download page. When you install cmake, choose the option to add cmake to your %PATH%
Download the latest git and install, choosing the option to add git to the system path for the current user.
NASM is used for building parts of libjpeg-turbo. If you're using a different libjpeg, feel free to skip this step. Otherwise, download v2.13.03 here, or find a newer version.
HTML Help Workshop
HTML Help Workshop lets you compile html into chm, which is a much easier format to navigate and read. You can get it from Microsoft.
Building Optional Dependencies
You can download the source bundle for most of the dependency libraries here : DepSources.7z
Some of our dependencies can be built with CMake, others require MSYS. We'll build as many as we can with cmake, since it is much easier to configure properly.
Building with CMake
Libraries that can be built with cmake include zlib, libpng, freetype2, physfs, libjpegturbo, enet, dumb, libTIFF, OpenAL, WebP, .
The build process with cmake is pretty easy. Navigate to your source directory, create a 'build' directory, cd to it, and then invoke cmake-gui. Configure the project, and when ready, hit generate. Then run make and make install. Make sure to set the cmake variable for the installation directory. It is named CMAKE_INSTALL_PREFIX. You can specify this option on the command line like others, or inside the gui.
Generally, I make a separate folder to install to, outside of the compiler directory. This saves us some problems but creates others.
With ZLIB and CMake, you need to configure it a little bit to get it to work. After configure runs the first time, set the install dirs to your install location.
With LibPNG, you have to set a few search directories so it can find where you just installed ZLIB.
Building Freetype2 with CMake is fairly straight forward. Just tell it where ZLIB and LibPNG are and it should work.
Note : I haven't been able to build a dynamic version of Freetype2,
and only the static lib gets built by default.
To build and configure LibJpegTurbo, you need to tell it where you installed NASM so it can find nasm.exe in the ungrouped entries in CMake. As well, when you build libjpegturbo, you need to make sure nasm.exe is on your path.
Building PhysFS with CMake should be easy.
Enet only builds a static lib. I altered the CMakeLists.txt file to create a shared lib as well. The source download for the updated code is above. Go to source distro.
Also, enet does not have an 'install' target for make. This means you need to install the dll, and static and shared libs and include folder manually. Move them to you installation folder's bin, lib, and include folders.
DUMB builds easily enough, if you clone it from git. In your source folder, checkout the source from git by using the following commands :
git clone https://github.com/kode54/dumb.git
Now configure everything normally and generate the project files. Once that is done, go back to your command line and call cmake again, this time telling it whether to build shared or static libs. For DUMB, the compile option that specifies static or shared is BUILD_SHARED_LIBS, and can take a value of 'On' or 'Off'. Specify this on the command line before calling make and make install. Repeat the step for each build you wish to create.
cmake -DBUILD_SHARED_LIBS=On ..
cmake -DBUILD_SHARED_LIBS=Off ..
LibTIFF is straightforward. You can build either shared or static libraries by toggling BUILD_SHARED_LIBS in the configuration screen.
OpenAL builds easily enough. Can't find an option for a static library though.
WebP only builds a static library.
Building with Autotools and Configure
Building with Autotools can be refreshingly sweet, or horribly bitter when you want to try and configure something. For the libraries that need to be built with MSYS, Configure, and Make it can be a pain trying to tell configure how to find a dependent library. For that reason, we will be installing to our *cough* compiler directory *cough* (bad, I know). Basic build with configure is easy though.
Open an MSYS terminal and type the following for most installations :
For each library :
For each install destination :
../configure --prefix=/drive/install/folder/destination --enable-static --enable-shared
Building LibGIF is straight forward.
FLAC doesn't need to be installed to the compiler directory, nothing depends on it, so set the install directory normally, using
XIPH.org and friends
For OGG and Vorbis, we'll need to install to our compiler directory as well as our install directory. To do this, simply run configure, make and make install twice, once for each install target. Ogg needs to be built before Vorbis, and Ogg and Vorbis need to be built before Theora.
Vorbis seems to look for ogg in mingw/lib, whilte Theora correctly looks for ogg in mingw/i686-w64-mingw32/lib. You may have to move things around to get Theora to compile correctly.
Building libOgg is pretty easy. Remember to install twice.
Vorbis depends on Ogg, which means it needs Ogg needs to be installed to the compiler directory for it to be found.
Theora depends on Vorbis and Ogg, which both need to be installed to the compiler directory.
LibOPUS is proving to be difficult. It depends on pkg-config being installed. So I added that to our packages. Tried to configure again, and ended up finding
it needs openssl too. Tried to download openssl and it depends on a minimum Perl version of 5.10, so I updated Perl by installing the latest Strawberry Perl for Windows. Strawberry Perl doesn't support Unix like slashes, so no go.
You may have better luck with MSYS2 if you need Opus support.
PkgConfig needs a special option to build with MSYS 1, because of the version of glib.
../configure --prefix=/path/to/install/ --enable-static --enable-shared --with-internal-glib
Getting the latest source code for allegro
The latest allegro version as of the time of the writing of this document is Allegro 5.2.5.
Allegro 5 source releases
Get the latest source releases of allegro from liballeg.org's download page. Extract the contents to find an allegro5 folder.
Cloning latest allegro with git
At the command line, (after installing GIT) , run the following commands to create a new allegro5 folder with the latest git source contained within.
git clone https://github.com/liballeg/allegro5.git
git checkout 5.2.5
git checkout master
Configuring allegro with CMake
After you have an allegro5 source folder, make a subdirectory called build, change to it, and invoke 'cmake-gui ..'
Building Allegro is the most complicated, due to all the dependencies and addons available for use. The configuration is the hardest part. Some of the available options for building allegro include the following (with their possible values given in brackets) :
- CMAKE_BUILD_TYPE = [Release | RelWithDebInfo | Debug | Profiling]
- SHARED = [On | Off] (whether to build static or shared libraries)
- WANT_MONOLITH = [On | Off] (whether to build a monolithic allegro library as an all in one
- WANT_EXAMPLES = [On | Off]
- WANT_DEMO = [On | Off]
- WANT_TESTS = [On | Off]
- WANT_DOCS = [On | Off]
You will need to configure and generate the cmake project for each library target and type that you require. For instance, there are 8 combinations of libraries available. I only compile the static and shared versions of the release and debug versions of allegro. If you want another configuration, you can specify it yourself. Then run mingw32-make and mingw32-make install for each target as you configure it.
Personally, when I build Allegro, I compile the examples, demos, and test driver in dynamic debug mode. Docs are compiled in static release mode for faster more efficient building. This makes for easier testing, sharing, and debugging of allegro.
Note: CMake uses forward slashes, not back slashes.
Create a deps folder
To make the configuration process easier, we'll use a hidden feature of allegro's cmake file. The deps folder. In the build folder for allegro that you created, make a 'deps' folder. Then copy the bin, include, and lib folders from your install directory with all your previously built libraries into the 'deps' folder before running cmake's configuration process.
The CMake script for allegro has gotten pretty smart and now correctly detects mingw-w64's compiler directory. This means we shouldn't have to worry about configuring and finding things like DirectX. GDIPlus on the other hand is detected incorrectly, and you need to set the include directory and the lib for this option. The GDIPlus header is located in c:\mingw\i686-w64-mingw32\include and the GDIPlus archive library is located in c:\mingw\i686-w64-mingw32\lib folder. Please set these options before generating your make files.
Once you've got allegro 5 configured the way you want it, press generate. Then run mingw32-make and mingw32-make install and you're good to go. You should now have a working install of allegro.
Building a CHM Manual for Allegro 5
Once you've built the html docs, you can use this special script (donated by some generous allegroite I can't remember at the moment) to create chm docs. You need HTML Help Workshop installed to build the chm docs. See the downloads and links at the top of the page. Clicky.
Extract the contents of generateCHM.7z to the allegro5/build/docs/html folder. Edit generateCHM.bat to use the correct program files location depending on the OS. If you have a 64 bit OS, the correct env variable is %ProgramFiles(x86)%. Edit the .bat file to use the correct location where you have HTML Help Workshop installed (look for hhc.exe, hhp.exe). Add that folder to your path using
After that it should be as simple as running the generateCHM.bat script, and you should now have an allegro-doc-refman.chm file or something similar.
Downloading latest binaries for Allegro 5
SiegeLord builds the official binaries for Allegro 5. You can find them just below. You'll also need the dependency package to go with it.
Allegro 5 Releases
Allegro 5 Dependency Releases
I maintain my own unofficial versions of the Allegro 5 library. See the download page on bitbucket for details :
Unoffical Allegro 5 binaries download page
Included are headers, libs, and dlls for developing with Allegro 5 and all of its dependencies. There are static, shared, release, and debug monoliths for allegro. Included are all the examples, tests, and demo programs compiled in dynamic debug mode. There are HTML and CHM docs included, as well as a primitive build environment provided by a .bat script. Run the "RunA525Examples.bat" file to set it up.
This guide was followed to produce the unofficial binaries. If I can do it, so can you. See the release thread on allegro.cc below for details :
Unoffical binary release thread
Well, that's all there is to see here folks! Hope you now have a brand spanking lovely new version of allegro 5 to play with!Happy Coding!!!111oneoneone
^^^ Back to the top ^^^