From Eric Botcazou on AD:

Allegro 4.1.14 is available at: [url http://sourceforge.net/projects/alleg]

This release is a Work-In-Progress release that adds features and corrects problems with regard to the 4.0 codebase. It is API (source) compatible with 4.0.0 on every platform, except for a few minor changes (see docs/html/api.html).

====================================================================
============ Changes from 4.1.13 to 4.1.14 (April 2004) ============
====================================================================

Elias Pschernig added a missing install dependency on Linux.

Elias Pschernig fixed a couple of problems in dat2c.

Angelo Mottola polished the MacOS X package builder script.

Elias Pschernig added a Jack sound driver to the Unix port.

Henrik Stokseth added support for debugging with DMalloc under Unix.

Eric Botcazou fixed detection of the ALSA 1.0 MIDI driver.

Eric Botcazou fixed compilation with --enable-color8=no under Unix.

Angelo Mottola made it possible to link against the Allegro framework with the allegro-config script under MacOS X.

Angelo Mottola changed the dynamic lib install name to major.minor to preserve binary compatibility under MacOS X.

Angelo Mottola fixed a bug in fixbundle with 32bpp icons and alpha channel under MacOS X.

Eric Botcazou improved the cross-compilation support on Linux.

Eric Botcazou restored the compensation code for end-of-frame in the FLI player.

Daniel Schlyder fixed potentially unsafe constructs in the Windows code.

Jees... Did that merit another release? What "unsafe constructs"?

Not IMO. I don't even know why it was since there's still a few things waiting to be done. There's new mixer code waiting to be put in, as well as an Allegro-DX mixer patch that improves conformance, as well as a patch for DIGMID to reduce CPU usage. And too, there was an identified joystick "bug" that nobody's commented on (on AD), as well as talk on how to better handle mouse input in Windows. Some of us were hoping 4.1.14 would've been the last WIP before 4.2, but I doubt it will be if the aforementioned things are still going to be worked on.

Improved MacOS X support justifies the new release, IMO.

As was discussed on the mailinglist, there's no problem in putting out WIPs a little more often than has been the case of late. That said, Allegro 4.2 should be released relatively soon. The stable 4.0 branch does not offer native MacOS X support, which in itself would justify 4.2. As there are other issues to fix (eg, thread safety) too, it may take a little longer.

In the spirit of improving things often and quickly, I don't see why this release is a bad idea ... if something useful has been added, publish it, even if it's not much. It's not like we can run out of version numbers or anything.

We should be grateful that people are still working on improving Allegro. And in their free time too..

Good job everyone who worked on this release!

Indeed. It's good for people to be working on this.

But I have a problem with the latest version...

SUSE 9.0Pro (which means ALSA 0.9.x). GCC 3.3.1 (default compiler with the distro). Configured, compiled, installed. BUT... none of the Allegro programs work. They all shut down with Signal #6. Any ideas?

I don't mind it... But this isn't really much a minor release if you compare the stuff done on this to the stuff done between 4.1.12 and 4.1.13 or some other version.

As Kitty Cat said, I don't see why they didn't wait a bit longer and throw some more stuff in. If you need a distro released every month, get the CVS snapshot.

As Evert said, this release is mostly for the MacOS X port.

Can you try if 4.1.13 works?

Allegro 4.1.13 had the same results as 4.1.14 - i.e., it crashed out with a signal #6.

Does it say anything else?

And what is the ouput of "make info"?

Also, could you try a debug build, for example like this:

cd allegro
./configure --enable-dbgprog
make
make install

Then run some example in gdb, e.g.:

gdb examples/ex12bit

Then when it aborts again, enter "bt", and post the output here.

Ah, how about this...

grabber: rawmidi.c:306: snd_rawmidi_open: Assertion `(inputp || outputp) && name' failed.
Shutting down Allegro due to signal #6
Aborted

...any use?

Interesting.
I get the same error message from my own programs using 4.1.12 when using the AUTODETECT drivers, except when I specify a configfile created by the setup program.

Most of my programs use such a config file, which is why I didn't notice the problem earlier.

Also using SuSE 9.0, with updates and patches from a week or two ago.

Hm, I don't have Alsa midi here, so that could explain why I don't get this. Can you try reconfiguring with:

./configure --disable-alsamidi
make
make install

And see if it fixes it?

And then someone will have to look up that function in the Alsa docs.. I say Tomasu since he wrote the driver

Disabling ALSA MIDI seems to make it work again, Elias. Grabber starts without any problem. It also plays MIDI files (thanks to OSS).

Ok, thanks for reporting this and testing - I guess it can be fixed now.

It seems like the ALSA function you quoted doesn't like the parameters it gets by Allegro - and therefore aborts the program.

Allegro's defaults must be screwed up. I'll try a rebuild later on and see what Allegro uses as default values and what is actually written to the config file (which, as I said, does work).

Finally had a look at the ALSA docs, and the problem seems to be the name parameter - it must not be 0. The attached patch should fix it, can't test it myself though right now. I'm also sending it to [AD].