Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 5 for Windows - Proposal for release builds

This thread is locked; no one can reply to it. rss feed Print
Allegro 5 for Windows - Proposal for release builds
Michał Cichoń
Member #11,736
March 2010

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:

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.

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Trent Gamblin
Member #261
April 2000
avatar

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.

Michał Cichoń
Member #11,736
March 2010

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?

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Trent Gamblin
Member #261
April 2000
avatar

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.

IonBlade
Member #3,521
May 2003
avatar

This is very helpful. Thank you for doing this :)

------

"I've got to choose my words carefully so that I'm not misunderstood, but I think there are fewer developers around today who think about making a good game. As a creator, I find that sad..." - Hideo Kojima

Matthew Leverton
Supreme Loser
January 1999
avatar

Are the 2005 and 2008 built with SP1?

Michał Cichoń
Member #11,736
March 2010

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)?

Are the 2005 and 2008 built with SP1?

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

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Trent Gamblin
Member #261
April 2000
avatar

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.

Michał Cichoń
Member #11,736
March 2010

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.

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Trent Gamblin
Member #261
April 2000
avatar

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.

Michał Cichoń
Member #11,736
March 2010

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.

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Trent Gamblin
Member #261
April 2000
avatar

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?

Michał Cichoń
Member #11,736
March 2010

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;
}

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Trent Gamblin
Member #261
April 2000
avatar

I see. According to this [comments.gmane.org] 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.

Sounds good.

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

Michał Cichoń
Member #11,736
March 2010

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. :)

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Trent Gamblin
Member #261
April 2000
avatar

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.

Michał Cichoń
Member #11,736
March 2010

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.

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Trent Gamblin
Member #261
April 2000
avatar

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

Elias
Member #358
May 2000

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).

--
"Either help out or stop whining" - Evert

Michał Cichoń
Member #11,736
March 2010

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).

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Trent Gamblin
Member #261
April 2000
avatar

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.

Michał Cichoń
Member #11,736
March 2010

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

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Go to: