I already posted this on the mailinglist, but it can't hurt to post it again here.
Allegro 4.2.1 is ready, but I want to stress-test the release before putting it up for public download. In particular, I'd like people to try to compile the source code (the more platforms the better) and report problems (if any). Tests with binary compatibility would also be useful.

You can grab a pre-release copy of the archives from http://www.eglebbk.dds.nl/allegro/.

Just in case there is any doubt, if your compiler is setup properly and more is required than
fix.sh $platform
./configure
make
for UNIX systems, or
fix.sh $platform
make
for DOS/Windows/MacOS X, that indicates a problem with the release.

Thanks.

Yes. It should work, but best to check.

OK I'll test it when I get home. I should not actually play around with allegro at work

In case you wanna know the error on a Window$ Xp Pro system, when launching any of the examples with the previous alleg42.dll, it crash saying that:

{"name":"590080","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/0\/a0166b862a39f18459e460e4bc1d49e5.jpg","w":710,"h":119,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/0\/a0166b862a39f18459e460e4bc1d49e5"}

Other than that, everything is working fine when using the new dll (just copied it from lib/mingw32 to examples/)

EDIT: compiles fine under windows when using dx8_mingw32

I was thinking so, and was doing the tips while you post ;-) I am not that dumb but thanks ;-D

Technically, it's RC2. RC1 was a while back but didn't go much beyond uploading and noticing that ithad some problems.

Revsion 7511 osx(intel) I get the following on install:

$ sudo make install
Password:
misc/mdhelper.sh /usr/local/lib /usr/local/include /usr/local/include/allegro /usr/local/include/allegro/platform /usr/local/include/allegro/internal /usr/local/include/allegro/inline /usr/local/bin
install lib/macosx/liballeg-4.2.1.dylib /usr/local/lib
(cd /usr/local/lib; ln -s -f liballeg-4.2.1.dylib liballeg-4.2.dylib)
(cd /usr/local/lib; ln -s -f liballeg-4.2.1.dylib liballeg-4.dylib)
(cd /usr/local/lib; ln -s -f liballeg-4.2.1.dylib liballeg.dylib)
install -d /usr/local/lib
install lib/macosx/liballeg-main.a /usr/local/lib
ranlib /usr/local/lib/liballeg-main.a
install -d /usr/local/bin
allegro-config script created in /usr/local/bin
make: *** No rule to make target `/usr/local/bin/fixbundle', needed by `generic-install'.  Stop.

No.
I will only accept bugfixes, no new functionality, let alone adding support for a new compiler. Sorry.

If someone makes one, sure, for 4.2.2 (say). But if no one volunteers to do it, it won't get done.

EDIT
I'm not sure about those MacOS X errors... I'll see if I can reproduduce and fix them on my laptop (didn't notice them before, but I may just have missed them).

No, it definately isn't.

I'm not exactly sure, as I've never used it myself. It's a tool that makes, or helps to make, an Application Bundle of your game+data. Beyond that, I don't know.

EDIT:

I dont really care about it, honestly I only got into that situation becuase I was trying to reproduce the fixbundle problem.

Do you know what the fix for that is?

Yes (iBook G4 running Tiger). The curious thing is that I can do sudo make install-fixbundle, which does install it correctly, after which make install works as it should. So whatever option depends on /usr/local/bin/fixbundle should probably depend on install-fixbundle instead... ?

I was just about to post a similar patch here (but just for the installation issue):

It's a bit different from yours in that it keeps fixbundle in the list of PROGRAMS, but removes the explicit dependency on install-fixbundle from the install target. Of course, it adds a /usr/local/bin/fixbundle: install-fixbundle rule, which is similar to the allegro-config rule. These follows the semantics of the other platform-specific makefiles, so I think it's the way to go.

Sure!

Actually, this is probably closer to my previous patch than it is to yours:

I removed the explicit install-fixbundle target, which was only referenced by $(INSTALLDIR)/bin/fixbundle: anyway. This makes it consistent with the $(INSTALLDIR)/bin/allegro-config: rule, though I wonder if that maybe shouldn't reference a phony install-allegro-config target instead.
Oh, this patch is actually untested, so kazzmir and juvinious should both test if it fixes the problem for them.