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

[About static, I never use static linking for several reasons, so no idea.]

How did you measure that? Most of the used memory usually will be textures and you can get the size of them just by knowing how many bitmaps you create anod how big they are. It sounds to me like that size somehow is hidden with OpenGL, with the way you measure memory. Maybe glTexImage2D(...) allocates the memory in some non-standard way or something.

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.

There's some sort of issue with linking on older versions of MinGW. I don't remember the details and I don't remember whether the problem was with static or dynamic linking.
I think Trent mentioned it a couple of times in discussions on the forum.

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.5.0 (maybe 4.4) on Windows is the oldest one that is able to build Allegro statically.

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.

Yeah that's the version I'm using. GCC 4.5.0.

@Michał Cichoń:
I'm not too sure how to use that info...I'm using CMake GUI to build allegro.
I'm not even sure how to set linker options etc for cmake, command line or not. I thought allegro decides on that based on the cmake settings you can change.

TDM GCC releases?

EDIT: ooo I'm blind. u see CXX flags/linker settings in cmake. do i just add to it whats not there?

EDIT 2: I added -lgcc_eh -static-libgcc -static-libstdc++ to CMAKE_EXE_LINKER_FLAGS
but now it bugs about redefinition of std::string stuff etc when making exes of demo/examples etc...I'm not sure how to do this right...
The libraries produced do make an exe for my own stuff, but same crash at application startup unless opengl is removed

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.

Yes, I did. Everything was done from scratch. Everything else works except OpenGL. When I compile Allegro without OpenGL support then everything works as static.
That's why I was wondering if it's the OpenGL libraries that come with MinGW causing the problem or something. I redid my whole compiler, MinGW, etc setup and as my Windows 7 install died just recently, I reinstalled everything and up to date GFX driver but still no good..
Is there even a way to update OpenGL?

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.

Ahh, ok. Where might I find that? I assume I can just search "intel's opengl drivers" I guess; I'll give that a try.

I think it's really silly, tbh...I heard about OpenGL being ended at 1.2 and about
how they had to add extensions and all that stuff, though I didn't really read all that much about it.

EDIT: All I seem to find is drivers for intel onboard gfx...my card is a nVidia GeForce 8800GT..

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.

Yeah I sorta thought that too.

I used this glview program I found to check my openGL support and it says my nVidia drivers support up to OpenGL 3.2...
It doesn't look like an OpenGL support issue at this rate...maybe the OGL libraries that come with MinGW are only 1.2 compliant?? (like libopengl32.a, glu32.a or whatever they called)

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.

Huh....yeah that's what I kinda thought....because since OpenGL and those kinda dependancies are rather a given on Windows systems or especially with Mac/Linux ....there would be no need.
I dunno...this issue has really stumped me. It's only windows with the problems I been having as well as the cpu usage issue suddenly returning or being so on things that really shouldn't be that hard. (ports to mac and linux show no issues at all)

Kinda frustrating because I finished my project after 7 months and just before release....it's not a total loss if I have to saay make an installer with the DLLs thats a good workaround if nothing more can be done.

Still gonna post about those 2 other issues as well but just trying everything I can myself first.

I wonder if anyone has got Allegro 5 to statically link with OpenGL use...

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.

Yeah..

I believe I've had this same problem on multiple computers as well.
It seems that Allegro 5 actually doesn't work statically, unless using DirectX.

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.

I tried the test and it was working. It showed stuff and wrote results to result.txt
I guess I just don't know how to prepare executable. The allegro examples don't work,(I think the resulting libraries don't ether) nor does compiling my own executables; they compile, etc but crash when run.
I tried following the list you gave me before but made no difference.
except I had no idea where to put
-s -DALLEGRO_SRC -DALLEGRO_STATICLINK -DALLEGRO_LIB_BUILD
in cmake gui and it does know to make static from the shared flag.

moreover, I dunno why things named '-static-mt' in such because my libraries etc have no names like that. (I know what it means but it's not naming them that way)

EDIT: I notice -DALLEGRO_SRC -DALLEGRO_STATICLINK -DALLEGRO_LIB_BUILD these don't seem to exist? for example -DALLEGRO_STATICLINK is actually -DSHARED and such is all whats listed in cmake GUI.

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.

It has named that way, because my build system use such postfix to differentiate between different compiler/lib configurations. You may try precompiled binaries availabla at http://allegro5.org/.

That way you will be able to use Allegro without problems. You will need those with "-static-mt-" suffix, which mean Allegro is compiled as static library and use statically linked run-time libraries.

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!

You're welcome.

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.

Yes, check out http://www.allegro.cc/files/.

No, that's the point of my post. The 4.4.0 pack does not include the static version of the Allegro libraries. The 4.5.0 pack does but as I have a MinGW with gcc 4.4.0 all set I was trying to use it.