Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 4.4.2 released

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Allegro 4.4.2 released
Michał Cichoń
Member #11,736
March 2010

OK. Complete Allegro 4.4 build. You will find links at the end of this post. They are very same like in the post above, archive files were updated.

What changed:
- main library is compiled in the A5 fashion
- jpgalleg, loadpng, logg were updated and build as DLL's
- monolith build was introduced, which mean all addons are integrated with main library

allegro-4.4.2-mingw-3.4.5.7z
allegro-4.4.2-mingw-4.2.1-sjlj.7z
allegro-4.4.2-mingw-4.4.0.7z
allegro-4.4.2-mingw-4.5.0.7z
allegro-4.4.2-mingw-4.5.2.7z
allegro-4.4.2-msvc-10.0.7z
allegro-4.4.2-msvc-8.0.7z
allegro-4.4.2-msvc-9.0.7z

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

Evert
Member #794
November 2000
avatar

Should the output from cmake be adjusted to match your naming convention?

The other way around, I would say...

Edgar Reynaldo
Member #8,592
May 2007
avatar

That would be fine too. The output from cmake is a little inconsistent currently though, as the release static version is named liballeg.a but the debug and profile static versions both have a -static suffix.

@Michal
I can't seem to get a test program to build when linking to the liballegro-4.4.2-monolith-mt.a library. It keeps giving me undefined references to allegro functions. It works fine when I use liballegro-4.4.2-mt.a though.

Something odd - liballegro-4.4.2-monolith-mt.a is 1160KB and is smaller than liballegro-4.4.2-mt.a, which is 1334KB. That doesn't seem right?

Is the liballegro-4.4.2-monolith-mt.a library a static library?

Matthew Leverton
Supreme Loser
January 1999
avatar

Evert said:

The other way around, I would say...

Allegro's naming convention is not verbose enough for distributing multiple binary versions (different Allegro versions, different compilers, monolithic builds, etc) of the libraries.

I don't see any problem with the two not being the same. If a person is unable to follow a tutorial because the file names aren't exactly the same, then he just needs to get a bit smarter.

Evert
Member #794
November 2000
avatar

I don't see any problem with the two not being the same. If a person is unable to follow a tutorial because the file names aren't exactly the same, then he just needs to get a bit smarter.

True.
I was mostly thinking of DLLs, but then, back when I used Windows, it was still common practice to keep all DLLs in one place. I think that's changed now, and you're supposed to keep them with the executable?
For static libraries, it really doesn't matter either way...

Arthur Kalliokoski
Second in Command
February 2005
avatar

Evert said:

it was still common practice to keep all DLLs in one place. I think that's changed now, and you're supposed to keep them with the executable?

I think it was to prevent crackers from installing their DLL's into system folders, so you need to keep your DLL in your own directory where you have write access. Of course crackers can still do that too...

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Edgar Reynaldo
Member #8,592
May 2007
avatar

Don't you guys think it is a little unconventional to have cmake produce libraries named differently than the pre built binaries? Otherwise in the docs and tutorials you have to have two different sections to cover linking both ways. No reason to add more confusion to the mix.

Michał Cichoń
Member #11,736
March 2010

I can't seem to get a test program to build when linking to the liballegro-4.4.2-monolith-mt.a library. It keeps giving me undefined references to allegro functions. It works fine when I use liballegro-4.4.2-mt.a though.

Something odd - liballegro-4.4.2-monolith-mt.a is 1160KB and is smaller than liballegro-4.4.2-mt.a, which is 1334KB.

That doesn't seem right? Is the liballegro-4.4.2-monolith-mt.a library a static library?

You're correct, monolith builds does not have symbols properly exported. I will look at the issue. Sorry, that is entirely my fault.

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

Peter Wang
Member #23
April 2000

I'm not so much worried about tutorials as breaking makefiles.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Michał Cichoń
Member #11,736
March 2010

I'm not using CMake. I have a script which generate Code::Blocks projects. That's where my binaries comes from.

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

Edgar Reynaldo
Member #8,592
May 2007
avatar

Okay then, that's fine. Well, I guess we can make tutorials that cover linking to the binaries produced by Cmake as well as the binaries produced by your projects.

Any chance of making a static monolith library for Allegro 4.4? That would be really nice.

Michał Cichoń
Member #11,736
March 2010

Yes, there will be static monolith library of A4.4. Right now I'm fighting with GCC 3.4.5 misfeature. When I solve that, I will produce new packages.

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

Edgar Reynaldo
Member #8,592
May 2007
avatar

Andrei Ellman
Member #3,434
April 2003

Personally, I'll be using Allegro 4.x for a while. This is because the project I'm working on relies a lot on paletted modes and MIDI which are not supported by A5, so I'm glad 4.x is still being maintained. But I will of course consider 5.x for future projects.

Last I heard, 4.4.x does not work on DOS but 4.2.x does. IIRC this involved an issue with draw_sprite_ex() which could not be resolved using just C code alone, and none of the devs were willing to delve into the world of machine-code haxx0ring. Back in 1997 when I was working on AllegroPak, I hacked my own machine-code versions of the various sprite-drawing functions (so I could add Z-buffering functionality), so I have some experience with the DOS machine-code. But alas, it's unlikely I'll have any time in the near future to look into this. Also, I seem to remember that someone was having an issue getting LOGG to work with DOS, but I recently managed to compile and run the LOGG test-programs in DOS so I couldn't find any issues with LOGG on DOS. Were there any other issues with DOS support on 4.4.x?

AE.

PS. Does anyone think we should rename the Allegro 4.x branch to "Allegro Classic"?

--
Don't let the illegitimates turn you into carbon.

Matthew Leverton
Supreme Loser
January 1999
avatar

Does anyone think we should rename the Allegro 4.x branch to "Allegro Classic"?

Only if we name series 5 "Allegro Pro."

Thomas Fjellstrom
Member #476
June 2000
avatar

Last I heard, 4.4.x does not work on DOS but 4.2.x does. IIRC this involved an issue with draw_sprite_ex() which could not be resolved using just C code alone, and none of the devs were willing to delve into the world of machine-code haxx0ring.

I think the issue is that no-one wants to touch the old crusty ASM anymore. And the DOS port is filled with it. Even its own calling convention.

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

Michał Cichoń
Member #11,736
March 2010

Edgar, try it now. This build should work.

Again, archives were replaced with new ones. This time symbols were exported with explicitly generated definition file. So all should be there.

allegro-4.4.2-mingw-3.4.5.7z
allegro-4.4.2-mingw-4.2.1-sjlj.7z
allegro-4.4.2-mingw-4.4.0.7z
allegro-4.4.2-mingw-4.5.0.7z
allegro-4.4.2-mingw-4.5.2.7z
allegro-4.4.2-msvc-10.0.7z
allegro-4.4.2-msvc-8.0.7z
allegro-4.4.2-msvc-9.0.7z

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

Edgar Reynaldo
Member #8,592
May 2007
avatar

Larkin
Member #11,125
July 2009

Appreciate your efforts to improve allegro4. I will use it for a while with my old projects.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Larkin
Member #11,125
July 2009

Quote:

Eliminated the need for old DirectX headers for the Windows port

How was this achieved ? No more need to deploy dx70_min.zip ?

 1   2 


Go to: