Hello,

Due to the problems with preparing builds for Windows I had decided to get rid of that. Few days of work bring me to quite satisfying results. I created Code::Blocks project file generator, which allow to quickly setup library with various configurations. There are result binaries:

• allegro-4.9.21-msvc8-bin.7z - Microsoft Visual C++ 2005

• allegro-4.9.21-msvc9-bin.7z - Microsoft Visual C++ 2008

• allegro-4.9.21-msvc10-bin.7z - Microsoft Visual C++ 2010

• allegro-4.9.21-mingw-bin.7z - MinGW GCC 4.4.1 TDM-2

Visual C++ binaries comes with shared and static libraries compiled with shared or static run-time. This give four different versions at the moment. Next, both debug and release configuration are available. This give eight combinations. Example:

• allegro-4.9.21-mt.dll - Shared, Static Run-Time, Release

• allegro-4.9.21-mt-debug.dll - Shared, Static Run-Time, Debug

• allegro-4.9.21-md.dll - Shared, Shared Run-Time, Release

• allegro-4.9.21-md-debug.dll - Shared, Shared Run-Time, Debug

• allegro-4.9.21-static-mt.lib - Static, Static Run-Time, Release

• allegro-4.9.21-static-mt-debug.lib - Static, Static Run-Time, Debug

• allegro-4.9.21-static-md.lib - Static, Shared Run-Time, Release

• allegro-4.9.21-static-md-debug.lib - Static, Shared Run-Time, Debug

Those variations are available for every Allegro plugin. Monolith build is also available (plugins compiled in).

MinGW binaries do not differentiate between static and shared run-time, so there are only four permutations.

As an extra static version of all dependencies are also included. While linking to Allegro using static version those have to be available.

Headers are provided for Allegro and PhysFS. All remaining libraries do not have public interface, so there is no way to use them directly.

PhysFS header was modified to honor ALLEGRO_STATICLINK definition.
This is the only change which affect public interface.

If may builds will make you happy, I will provide them for every next Allegro release. There is also a slight chance for monolithic builds for other platforms.

Any critique and comments are welcome.

Sounds good to me. If you want to start making the allegro5.org binaries that would be sweet. I think these are better than what I offer presently. How is compatibility between TDM and official MinGW? The monolith builds are very nice.

As far as I know TDM is not compatibile with official MinGW GCC binaries due to changes in exception model (at least). I can prepare binaries using any version of GCC. Is there any specific one which is required?

Well I personally prefer the official mingw builds... and I think most people use those still. 4.4 is good, though if you don't link libstd++ statically it requires an additional dll. 4.2.1 was never an official stable release, but it's the one I've used the most and trust the most other than maybe 4.4. I think 4.4 would be ideal, but the dll requirement might bug some people. It doesn't bother me, however. There's 4.5 but last I tried it it didn't produce correct code... So it's between 4.4 and 4.2.1 if you ask me. Either one is ok I guess, and they're compatible.

This is very helpful. Thank you for doing this

Are the 2005 and 2008 built with SP1?

OK. I have following versions of MinGW:
3.4.5 (default)
4.2.1-sjlj
4.4.0
4.5.0

I will setup configuration for those.

Shoud I use -shared-libgcc, -static-libgcc switches (which I think may be equivalent to /MD, /MT switches for MSVC)?

Yes. I my compilers are up to date.

Edit:
New build is available for download. Any comments are welcome.
allegro-4.9.21-mingw-3.4.5-bin.7z
allegro-4.9.21-mingw-4.2.1-sjlj-bin.7z
allegro-4.9.21-mingw-4.4.0-bin.7z
allegro-4.9.21-mingw-4.5.0-bin.7z
allegro-4.9.21-msvc-10.0-bin.7z
allegro-4.9.21-msvc-8.0-bin.7z
allegro-4.9.21-msvc-9.0-bin.7z

I just tried 4.4, but found I had the problem I described on [AD] a little while back about TLS not working. I don't recall if it was 4.4 related or not. If it is, I guess it should be built with WANT_DLL_TLS enabled. I'm going to try 4.2.1 now.

Edit: I have more info. Apparently, MinGW GCC 4.4 doesn't support thread local storage with __thread. Nothing prior to it does either. With version 4 of gcc they apparently just stopped throwing an error when it is used, which made me think it was actually working. Instead, all threads share the same state. I don't know about GCC 4.5, it just doesn't seem to work at all for me. Applications just won't launch.

So I think the only thing we can do for now is to use -DWANT_DLL_TLS... I've tested it, a while back, and it does work unlike __thread. The downside is, Allegro must be compiled as a DLL for it to work. So that rules out static linking completely unless you use only 1 thread.

Could you post link to discussion about TLS? Reading the TLS code I noticed that GCC 3.x require TLS implementation thought DllMain. For all 4.x everything should work. WANT_DLL_TSL may indeed fix problem for shared Allegro builds, but what with static ones?

I noticed that Allegro still have issues with finalization. D3D driver crashes if I manually shut down primitives addon before destroying display. At least one primitive have to be drawn on the screen. Without that addon is not entirely initialized.

MSVC debug builds does not contain debug info, that's a bug in project setup. It will be fixed in next iteration of builds.

Edit:
I see. I will enable DLL_TSL for 4.4.0 builds.

This is the discussion I learned about this from:
http://lists.freedesktop.org/archives/pixman/2010-May/000187.html

I know the code is set up to use __thread for MinGW 4+, but it's wrong, it needs to be fixed. There nothing that can be done for static versions, unfortunately. We didn't support static builds on 3.4.5, we can't on 4.4 either (still not sure about 4.5).

The primitives crash sounds like a legitimate bug. As for drawing one primitive, you are now technically required to call al_init_primitives_addon for things to work.

To summarize TLS problem:
- 3.4.5 - use DLL, does not have __thread
- 4.2.1 - use __thread
- 4.4.0 - use DLL, __thread do not work
- 4.5.0 - unknown, most likely __thread is still broken

It this right?

About primitives. I call init and shutdown for all used addons. Crash occur only for Direct3D at the moment.

No, it's use DLL for ALL versions of MinGW except possibly 4.5.0.

About your crash, can you post some code, maybe an example?

I see. According to this thread, MinGW 4.5.0 have TLS support. This is also the case for TDM GCC 4.4.* releases.

I just enable TLS_DLL for all GCC < 4.5.0.

There is simplest example:

int main(int argc, const char* argv[])
{
  al_init();
  ALLEGRO_DISPLAY* display = al_create_display(1440, 900);
  al_init_primitives_addon();
  al_draw_line(0, 0, 100, 100, al_map_rgb(255, 255, 255), 1.0f);
  al_shutdown_primitives_addon();
  al_destroy_display(display);
  al_uninstall_system();
  return 0;
}

Sounds good.

I believe the bug your reported is fixed in svn. Could you please verify?

Yap, fix works. The crash is no more.

Which version of build you need for testing? Building everything from ground up takes almost three hours, building specific version take a few minutes.

I think I will prepare for you monolith builds for all supported GCC version.

Notice, that even GCC 3.4.5 now have static version of Allegro.

But do they work properly? AFAIK TLS doesn't work in most versions of mingw with static libs.

Yes, that's the problem. The may compile and appear to work, but actually fail when you use multiple threads. As a test, write a program that sets some TLS state, spawn a thread and set the same TLS state in the thread, and check the value in the main thread. It's likely to have changed.

You have right. TLS doesn't work at all in static version of Allegro compiled with MinGW < 4.5.0. Sad.
Because of that fact I just do not compile those.

New MinGW binaries are compiling right now. They will be available in next hour.

Edit:
I don't have to write specific test cases. Creation of display use TLS, so if it is not working, creation will fail with segmentation fault.

Thanks Michał. I'll test the 4.2.1 binaries.

Is there something we can do to make TLS work? Since there exists a pthreads for Windows it must be possible to set TLS data (without a DLL).

Brand new MinGW binaries:
allegro-4.9.21-mingw-3.4.5-bin.7z
allegro-4.9.21-mingw-4.2.1-sjlj-bin.7z
allegro-4.9.21-mingw-4.4.0-bin.7z
allegro-4.9.21-mingw-4.5.0-bin.7z

Edit:
I'm still uploading those files, please wait a few minutes if link do not work.

Archives contain only monolithic shared version of Allegro, except 4.5.0. This one have both shared and static version available.

Trent, if you require any other version, let me know. I'm compiling only parts because GCC is horribly slow under Windows. There is also hot and my CPU don't like to work in such "extreme" environments.

Elias, I do not know any universal method. I think TLS from WinAPI could be used, with assumption that user create threads trough Allegro API (TLS can be explictly initialized/finalized for thread).

If the user can only use Allegro threads, it may be possible. I think the issue we had before was that we had no threading api, thus there was no way to clean up TLS data after a user thread exited.

Good news. Examples working fine for all MinGW builds. A few do not compile: ex_curl, ex_gp2xwiz, ex_iphone, ex_d3d, ex_ogre3d. Fail reason for first three is obvious. ex_d3d complains for missing d3dx9.h, which is not in my SDK. ex_ogre3d fail because I do not have Ogre.

ex_audio_props crash from unknown reason after creation of window.

GCC 4.5 did the job. I did not encounter any weird crash. I guess compiled code is fine for Allegro.

About TLS, I will wait for Elias opinion. I do not have knowledge about design of such Allegro API part.

Edit:
There is most current release, revision 13457.

All found bugs were removed. Builds now work as expected (at least for me ). All comments are welcome.

Compilation time: 154 minutes, 43 seconds

allegro-4.9.21-mingw-3.4.5-bin.7z
allegro-4.9.21-mingw-4.2.1-sjlj-bin.7z
allegro-4.9.21-mingw-4.4.0-bin.7z
allegro-4.9.21-mingw-4.5.0-bin.7z
allegro-4.9.21-msvc-10.0-bin.7z
allegro-4.9.21-msvc-8.0-bin.7z
allegro-4.9.21-msvc-9.0-bin.7z