For literally YEARS I've never succeeded in compiling Allegro 4, WIP or now 5 RC1 statically.
All examples crash and nothing works.
I've posted about this before, and I was told it's likely that one of the static libs I'm linking with is corrupt.

I did a lot of testing and now I know what is causing it, but not why it's happening.

I re-setup my compiler, (Code::blocks IDE with MinGW, the latter was installed from it's mingw-get downloader) and all libraries, etc were fresh and new, but this problem still occurs.
I wonder if anyone has succeeded in using Allegro 5 statically at all, as here's the cause:

It's OpenGL. If you include it in cmake config, then all examples crash if they use it or not. (it made me have to exclude primatives addon as well as it referenced opengl stuff though in the source it seems to try not to if opengl isn't used..)
As soon as you remove OpenGL from the mix, then all static linking works and no crashes. Add support for OpenGL (WANT_OPENGL in cmake gui checked) and once again every single example crashes before they even make a window, regardless of if they use it or not. (even direct3d example crashes)

I'm assuming the problem lies in libopengl32.a and the static opengl related libraries themselves? (when using DLLs, it all works fine) a fresh install of MinGW replaced them with new copies, but still nothing solves this problem....

I want to use OpenGL for my programs so It's needed for me.

I also noticed that memory usage is much better with such:
A project of mine that showed to use 38-40MB of ram with 4.9.x
now only uses 16MB with OpenGL and 48-60MB with DirectX9 with Allegro 5 RC1

I was using the task manager/Resource Monitor in Windows 7 Ultimate.
I could be wrong...it shows 27MB now. Probably not a very good thing to use to measure it. Maybe it's wrong about cpu usage as well; I find that's returned and the more TTF text is on the screen the worse it gets, also with loading a bunch of images in succession for an animation (unless they're really small)...(all of this only under windows AFAIK) I should probably ask about those issues in seperate threads as not to get too off topic.

The reason why I want to use static is so I don't have like 10+ DLLs all over the place. This was especially difficult/messy for non programmers testing my programs.
It works well in Linux/Mac OS X, but not Windows...If I were to guess, I think it's surely a problem with the static OpenGL libs...or at least the ones provided with MinGW...I wonder what would happen if I tried such with a different compiler, etc...

At worst case, I guess I could always use something like Inno Setup, etc and make an installer, copying the DLLs to the user's system folders, which would be pretty nice actually.

Assume you're using MinGW GCC 4.5.0. To compile Allegro as static library with static run-time libraries use following switches:

Switches for source files:
-s -DALLEGRO_SRC -DALLEGRO_STATICLINK -DALLEGRO_LIB_BUILD

Switches for linker:
-lgcc_eh -static-libgcc -static-libstdc++

Switches for executable:

Switches for source files:
-s -DALLEGRO_STATICLINK

Switches for linker:
-lgcc_eh -static-libgcc -static-libstdc++

Libraries:

Allegro and add-ons (list all your application, you may list all they will be ignored if not used):
allegro-5.1.0-static-mt
allegro_audio-5.1.0-static-mt
...

Direct dependencies (libraries used by Allegro):
libFLAC-1.2.1-static-mt
libvorbisfile-1.2.3-static-mt
libvorbis-1.2.3-static-mt
libogg-1.1.4-static-mt
dumb-0.9.3-static-mt
zlib-1.2.5-static-mt
physfs-2.0.0-static-mt
freetype-2.4.2-static-mt

Indirect dependencies (DLL's availabe in system):
gdiplus
uuid
kernel32
winmm
psapi
opengl32
glu32
user32
comdlg32
gdi32
shell32
ole32
advapi32
ws2_32

GCC 4.4.0 is in fact first version which is able to do the job. This is tricky, because MinGW team do not keep the consistency with old releases. You have to manually force linking to the static run-time.
TDM GCC releases are better IMHO, because they are prepared to build standalone executables. You have to force shared run-time if you want, because defaults settings follow old MinGW spirit.

Please use <quote> for quoting.

Did you rebuild everything? I mean Allegro, all statically linked libraries and your application.

If only OpenGL is your problem, verify if it is installed correctly. Under Windows check if your GFX driver is installed correctly. If not, Windows provide you OpenGL 1.2 which is to old for Allegro to use.

You will need to grab intel's latest driver package and see if that helps at all. Otherwise you're stuck with Microsoft's broken OpenGL.

If that doesn't work, intel's OpenGL drivers are known to be somewhat lacking.

Sorry, I was being unclear, I don't think there are separate drivers for OpenGL. Just the regular Graphics drivers should include the OpenGL support.

Well OpenGL development did seem to stall a couple times. But its now up to OpenGL 4.x, so it definitely hasn't stopped at 1.2. OpenGL 2 was released in 2004, about 7 years ago.

append:

My bad. I seem to have gotten the impression that you had an Intel IGP (Integrated Graphics Processor). If you have a Gforce, just grab the latest NVidia drivers, and it should support OpenGL 4 by now. And with that card, it WILL have proper FBO support.

libopengl32.a should only be a link library, that is its just there so mingw knows how to link to OpenGL32.dll. If glview is showing 3.2, allegro should be as well.

As far as I know, you can't statically link with OpenGL. Much like you can't statically link with core windows dlls. But then I don't think theres a real static opengl lib, so it shouldn't be a problem.

In attachment you can find test_driver compiled with MinGW GCC 4.5.0. Everything is linked statically so there is one and only executable without any additional dependencies.
I prepared for you a short test. You will find two files do_test_gl.bat and do_test_gl_1_2.bat. They launch primitive test, first force any OpenGL version, second force OpenGL 1.2.
If they do not work, that's mean you have something wrong with your OpenGL libraries. Otherwise you're doing something wrong while preparing your own executable.

Those aren't CMAKE flags, rather defines for the compiler. Also ALLEGRO_LIB_BUILD and ALLEGRO_SRC are NOT to be used for anything but the allegro library itself. You do however need to set ALLEGRO_STATICLINK when statically linking to allegro in your own programs. It needs to be set before you include any allegro headers. Either using a gcc -D flag, or #define FOO before the #include lines for allegro.

OoooO! I didn't know that static binaries were available! Always saw 'em as DLLs.
I'm going to give this a try! Hopefully it fixes my issue. I'll post back if I have any problems.

EDIT: YES!! It's working!! YAY!
I noticed I had to link with flac and dumb libs tho i don't use them. flac gave me a problem an undefined ref to ntoh@14 or something....but I used the copy I had and then it was ok. When I ran my visual novel interpreter, it started up no problem and everything worked! Except the rain from thunderstorm was black and other such things. That's the premultiplied alpha stuff of 5.0.0 RC1/RC2 I'm assuming. maybe I'll use that flag that shuts it off or else modify to support it.

Thanks SO much for your help!

Are there prebuilt static binaries for MinGW gcc 4.4.0?.

It's the first time I'm dealing with static linking and I'm having the same problems as Mallie. I usually build the shared libs with gcc 3.4.5 but now I wanted to send a single exe and it seems Mallie had luck using the prebuilt libraries.

As Mallie, I built Allegro and can get my program to compile but it crashes. The MinGW 4.4.0 binaries here at allegro.cc don't include the static libraries and since allegro5.org now redirects to the Allegro homepage I'm wondering if there are static binaries for 4.4.0 or if they're only available for gcc 4.5.0.

Thanks.