What's in the Binary Packages

The binary packages contain the complete Allegro library with all of its addons and third party dependencies. Each package is designed to work with a particular compiler version. You must download the version for your compiler.

The supported compilers are:

• MinGW 3.4
• MinGW 4.2
• MinGW 4.4
• MinGW 4.5
• MSVC 8 (2005) with SP1
• MSVC 9 (2008) with SP1
• MSVC 10 (2010)

If the compiler you use is not on the list, then you will have to build Allegro yourself.

The binary package contains three folders. The include folder contains all of the header files. Note that the header files are specific to the compiler and its version, and thus are not compatible with other compilers. The lib folder contains the libraries that you will need to link against. Those too only work for the particular compiler they are designated for. The bin folder contains the various DLLs that your program will be dependent upon (if you do not static link).

Understanding the Allegro 5 Addons

Allegro 5 is modular, and as such, you must link to a variety of different libraries depending on the functionality you use. The current libaries are:

• allegro - the core functions
• allegro_main - a compatibility libarary that allows int main() to work across all compilers. Do not confuse this with the base allegro library. It does not include any functionality. It is only required on OS X.
• allegro_acodec - audio codecs (e.g., OGG)
• allegro_audio - the basic audio subsystem
• allegro_color - converting between various color formats
• allegro_dialog - native dialogs (e.g., Open File)
• allegro_font - basic bitmap fonts
• allegro_image - image formats (e.g., JPEG, PNG)
• allegro_memfile - an interface to load files from memory
• allegro_physfs - an interface to load files from abstract locations (e.g., a ZIP file)
• allegro_primitives - basic drawing functions (e.g., rectangles, lines)
• allegro_ttf - loading TTF fonts

Some of the libraries depend on each other. See the Getting Started guide for more details.

Library Naming Conventions

The binary packages contain each of those addons in a variety of formats. This leads to a very verbose naming system that looks like:

    allegro[_module]-[version][-static,-monolith]-[mt,md][-debug]

The addon libraries you use must match the build type of the base Allegro library you link against. The third party libraries (e.g., libogg) are all static versions, but you still must use the same mt/md build.

Dynamic, Static, or Monolith

If the library does not include -static or -monolith then it is the dynamic version. This means that the executable will be dependent on the corresponding DLL file in the bin folder. As such, you must include those DLLs when distributing your project.

The static version means the DLL is not required. Not every compiler supports this option. When using the static version of Allegro you must define ALLEGRO_STATICLINK before including any Allegro headers.

The monolith version is a one-size-fits-all build of Allegro. When you link against allegro-monolith, you do not need to link to any other Allegro library. (And so there is no such thing as allegro_module-monolith.) The monolith build can also be static; if so, the same things mentioned above regarding the static build apply to it.

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.

Release vs Debug

Builds marked as debug are meant for debugging. It is recommended that you use debug when you are testing and developing your project. When you distribute your program, you should use the standard non-debug builds.

Configuring your IDE

Coming soon.