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.

gcc version 4.1.1 (Gentoo 4.1.1)

 Some drivers will be built as dynamic modules.
 Enabled modules: dga2 jackdigi fbcon vga ossmidi artsdigi esddigi alsamidi alsadigi ossdigi
 Disabled modules: svgalib vbeaf sgialdigi
 Generated code: multithreaded, little endian, i386 asm, MMX, SSE
 Generated libraries: shared release
 Compiled programs: dynamically linked release
 Ignoring compiler warnings.
 X11 support: enabled with: Xext Xpm Xcursor XShm XF86VidMode XDGA XIM
 Linux console support: enabled

Compilation went fine without errors or warnings. At least I didn't see any warnings.

What do you mean by that? Should I try to run allegro 4.2.0 programs using 4.2.1 .so's?

Yes. It should work, but best to check.

Is 4.2.1 mainly bug-fixes?

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

I did a ./configure --enable-dbglib=yes --enable-proflib=yes --enable-static=yes --enable-staticprog=yes, make and compiled for a while. However, it stopped with a

Need to install it, but it seems it compiled everything without problem with Ubuntu (gcc 4.0.3)

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

Install the DirectX headers.

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

Windows binaries are available for testing:

http://www.allegro.cc/files/4.2.1-RC1/

The MSVC 8 binary has a new static runtime version (alleg_s_crt.lib) that will make distributing your Allegro applications a lot easier. Note that if you use it with add-on libraries, you'll have to compile them with the static runtime (/MT) switch.

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

On revision 7511 on osx I got the following doing a sudo make uninstall.

...
rm -f /Library/Documentation/Help/Allegro.bundle/*
rmdir /Library/Documentation/Help/Allegro.bundle
rmdir: /Library/Documentation/Help/Allegro.bundle: No such file or directory
make: [uninstall] Error 1 (ignored)
All gone!

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.

Hi people!
I'm not a makefile expert.. but for this new release can be done a makefile for Windows/Watcom (not DOS/Watcom)?

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

kazzmir mentioned that he just deleted the fixbundle target to get it to install, but that doesn't sound right. What does fixbundle do?

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:

Kazzmir's error just meant that he didn't install the Apple help bundle, so there's nothing to delete. The makefile uses -rm to keep the makefile running, so it's only a cosmetic error. This is used elsewhere in the uninstall targets, too.

To avoid the message, you can use code like this:

Index: makefile.osx
===================================================================
--- makefile.osx        (revision 7519)
+++ makefile.osx        (working copy)
@@ -272,8 +272,7 @@
          | xargs -n 1 rm -f
        -sed -n -e "s,^@@\(struct\|typedef\).*@\([a-zA-Z0-9_]*\),$(MAN_DIR)/man3/\2.3,p" docs/src/allegro._tx \
          | xargs -n 1 rm -f
-       -rm -f $(HELPBUNDLE)/*
-       -rmdir $(HELPBUNDLE)
+       @test -d $(HELPBUNDLE) && rm -fR $(HELPBUNDLE) || true
 
        @echo All gone!
 

Is this worth modifying throughout?

Pete

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?

I can't reproduce Juvinious's error, either from my SVN, a clean SVN checkout, or the latest version (the .tar.gz) from Evert's website. Can you confirm it, Evert?

However I did see a deprecated warning for file_size, which I replaced with file_size_ex and committed.

Pete

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

Right, gotcha. The secondary problem was that uninstall doesn't remove fixbundle, and I forgot to check. So, make install never had to do any actual work to install it.

Please test this patch to fix both issues.

Pete

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.

Fine by me - can you breed some kind of mutant offspring of our two patches to fix both problems...?

Pete

[edit]
As kazzmir pointer out to me on IM:

In the old days, fixbundle wasn't installed by default, you had to do it explicitly with sudo make install-fixbundle. That's why things are the way they are.

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.

Evert, your last patch fixes the problem for me.

I still had to make install-fixbundle before make install to get it to work.

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

You didnt apply the patch.

Obviously, I misunderstood and I thought it was applied to the repository.
/me cleans it out and tries again

[edit]
Ok it works.

Great; I'll commit it later today when I'm back home.

EDIT: Commited.

GCC 3.4.2 (MinGW) under Windows XP Professional. Everything OK with the compilation stage. I tested binary compatibility using some of my games and the compiled examples from 4.2.0, no problems whatsoever.

Ok, good to know. I should finally have some time to do a third RC tomorrow or the day after.

I've just posted a patch to the [AD] list that fixes two issues with pack_fopen_chunk(). Could you make sure it is included?

AE.

Well, I get this during 'make' on linux (x86_64) with gcc 4.1.1 - just me?;

gcc -DALLEGRO_MODULES_PATH=\"/usr/local/lib/allegro\" -DHAVE_CONFIG_H -I. -Iinclude -Iinclude/allegro -I./include -I./include/allegro -DALLEGRO_LIB_BUILD -mtune=k8 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -Wall -Wno-unused -fPIC -DALLEGRO_SHARED -DALLEGRO_MODULE -c ./src/unix/jack.c -o obj/unix/module/jack.o
gcc -shared -fPIC -DALLEGRO_SHARED -o lib/unix/alleg-jackdigi.so obj/unix/module/jack.o -L/usr/lib64 -Wl,--export-dynamic `pkg-config --libs jack`
gcc -DALLEGRO_MODULES_PATH=\"/usr/local/lib/allegro\" -DHAVE_CONFIG_H -I. -Iinclude -Iinclude/allegro -I./include -I./include/allegro -DALLEGRO_LIB_BUILD -mtune=k8 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -Wall -Wno-unused -c ./setup/setup.c -o obj/unix/setup.o
gcc -s -L/usr/lib64 -Wl,--export-dynamic -o setup/setup obj/unix/setup.o -Llib/unix -lalleg-4.2.1 -lalleg_unsharable -lm
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_is_486'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_is_cpuid_supported'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_cx_w'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_is_cyrix'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_is_fpu'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_get_cpuid_info'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_cx_r'
collect2: ld returned 1 exit status
make: *** [setup/setup] Error 1

Did you pass any options to ./configure ?

I have an amd64 too and I have no problems, but I pass --disable-asm to configure.

I get that passing no options, just testing --disable-asm...

...

Same

I'm running glibc 2.4, I'm assuming there's no dependancy on linuxthreads or other problem related to that?

Here's the output I get from './configure' in case it's useful (looks sane to me, but as something's wrong it might be here! )

checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking whether -fomit-frame-pointer is safe... yes
checking whether an include prefix is needed... yes
checking how to run the C preprocessor... gcc -E
checking whether a C++ compiler is installed... yes
checking whether linker works with -s option... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking whether ln -s works... yes
checking for ldconfig... /sbin/ldconfig
checking for makeinfo... /usr/bin/makeinfo
checking for install-info... /usr/bin/install-info
checking for processor type... amd64
checking whether -mtune is supported... yes
checking for asm prefix before symbols... ""
checking whether byte ordering is bigendian... no
checking for MAP_FAILED... yes
checking for sched_yield in -lc... yes
checking for constructor attribute... yes
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking whether --export-dynamic linker flag is supported... yes
checking for dlopen in -ldl... yes
checking soundcard.h usability... no
checking soundcard.h presence... no
checking for soundcard.h... no
checking sys/soundcard.h usability... yes
checking sys/soundcard.h presence... yes
checking for sys/soundcard.h... yes
checking machine/soundcard.h usability... no
checking machine/soundcard.h presence... no
checking for machine/soundcard.h... no
checking linux/soundcard.h usability... yes
checking linux/soundcard.h presence... yes
checking for linux/soundcard.h... yes
checking for _oss_ioctl in -lossaudio... no
checking for supported ALSA version for digital sound... yes
checking for supported ALSA version for MIDI... yes
checking for esd-config... /usr/bin/esd-config
checking for esd_open_sound... yes
checking for artsc-config... no
checking for alOpenPort in -laudio... no
checking for soundcard.h... (cached) no
checking for sys/soundcard.h... (cached) yes
checking for machine/soundcard.h... (cached) no
checking for linux/soundcard.h... (cached) yes
checking linux/awe_voice.h usability... yes
checking linux/awe_voice.h presence... yes
checking for linux/awe_voice.h... yes
checking for _oss_ioctl in -lossaudio... (cached) no
checking for OSS sequencer support... yes
checking sys/procfs.h usability... yes
checking sys/procfs.h presence... yes
checking for sys/procfs.h... yes
checking for getexecname in -lc... no
checking for X... libraries /usr/lib64, headers
checking for XMissingExtension in -lXext... yes
checking X11/xpm.h usability... yes
checking X11/xpm.h presence... yes
checking for X11/xpm.h... yes
checking for XpmCreatePixmapFromData in -lXpm... yes
checking for XcursorImageCreate in -lXcursor... yes
checking for XShmQueryExtension in -lXext... yes
checking for XF86VidModeQueryExtension in -lXxf86vm... yes
checking for XDGAQueryExtension in -lXxf86dga... yes
checking for XOpenIM in -lX11... yes
checking sys/io.h usability... yes
checking sys/io.h presence... yes
checking for sys/io.h... yes
checking linux/joystick.h usability... yes
checking linux/joystick.h presence... yes
checking for linux/joystick.h... yes
checking linux/input.h usability... yes
checking linux/input.h presence... yes
checking for linux/input.h... yes
checking linux/fb.h usability... yes
checking linux/fb.h presence... yes
checking for linux/fb.h... yes
checking vga.h usability... no
checking vga.h presence... no
checking for vga.h... no
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_create in -lpthread... yes
checking for pkg-config... /usr/bin/pkg-config
checking for jack_client_new... yes
checking for ANSI C header files... (cached) yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking whether time.h and sys/time.h may both be included... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking sys/utsname.h usability... yes
checking sys/utsname.h presence... yes
checking for sys/utsname.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking return type of signal handlers... void
checking for mmap... yes
checking for mprotect... yes
checking for memcmp... yes
checking for mkstemp... yes
checking for stricmp... no
checking for strlwr... no
checking for strupr... no
checking for vprintf... yes
checking for stat64... yes
configure: creating ./config.status
config.status: creating makefile
config.status: creating allegro-config
config.status: creating include/allegro/platform/alunixac.h
config.status: executing default commands
Some drivers will be built as dynamic modules.
Enabled modules: dga2 jackdigi fbcon ossmidi esddigi alsamidi alsadigi ossdigi
Disabled modules: svgalib vbeaf vga sgialdigi artsdigi
Generated code: multithreaded, little endian, amd64 asm
Generated libraries: shared release
Compiled programs: dynamically linked release
Ignoring compiler warnings.
X11 support: enabled with: Xext Xpm Xcursor XShm XF86VidMode XDGA XIM
Linux console support: enabled

Try doing a "make clean", then start over. and if that still errors, do a make distclean. and make sure config.cache isn't around before you ./configure

Same after 'make distclean'...

I'll start randomly disabling things to try to work out what's breaking here But feel free to throw suggestions my way if anyone has any ideas?

You don't need to pass --disable-asm, it's implied (well, there is one asm routine in there: it wraps the CPUID instruction). I have an AMD64 as well and can confirm that it works for me.
However, I don't have GCC 4.1.

"make depend" should do, though I think it's implicated by "make distclean"

Hmm... Can confirm same behaviour with gcc 3.4.6 and a 4.2.0 development build I have hanging around. Must be something to do with my system as nobody else seems to have seen this... Dependancy issue perhaps...

Hmm... just to have asked, your system is running in 64 bit mode, right?
To the best of my knowledge, it should work in 32 bit mode, but if it detects and AMD64, assumes a 64 bit environment but uses the 32 bit dependencies (or the other way around, uses 32 bit dependencies while compiling the 64 bit library in 32 bit mode), that may cause the problem.

Well I've rebuilt dependancies, and can now compile happily if I pass --disable-asm to configure - is this expected behaviour? How's it implying this if I shouldn't have to pass it, as it appears not to in my case?

It most definately is not.
From a frechly unpacked archive, Allegro should build normally when you run

./fix.sh unix 
./configure
make

That's it. Anything more than that indicates a problem with the build process. Using an Allegro release (note: not a snapshot) you should never need to run make depend and you should never need to pass options to configure to compile Allegro. You most certainly should never need to pass --disable-asm.

Compiling on AMD64 automatically implies --disable-asm, since all the asm code is 32 bit assembler and incompatible with a 64 bit library.

Anyway, you didn't answer my question:

Yes I'm running native 64 bit.

I realise the asm is 32 bit, and so necessarily can't be built into a 64 bit binary. What I meant was, how does configure determine it's running on a 64 bit platform? As it appears to be failing that detection on my system.

I took a look at the configure script, but was pretty tired last night and got a little lost

At the top of aclocal.m4:

Now... if they've changed the asm syntax (*again*) then maybe that can fail. Can you try it manually and see if it compiles?
On the other hand, looking at your configure output, it appears to detect the processor type just fine:

EDIT: remember to re-run autoconf if you make changes to aclocal.m4 or configure.in

No, that certainly compiles and seems to give the expected output... Very odd... Haven't managed to find anything obvious causing the problem, but will try to take a proper look later as I have to dash off for a few hours.

(have found a few other people with this issue on amd64, but still appears to be a very small minority)

Can you post the linker line that links the library?
The problem is with the CPU detection (this is the only difference between the AMD64 build and a generic C build). The CPU detection code used is in src/i386/icpu.c, with helper functions in src/amd64/acpus.s (most of these are dummy functions).
Can you check if acpus.s is properly compiled and linked in? Can you check the symbol names in the generated .o file? configure claims there is no prefix, so they should have the proper names, but best to double check that.

Just wanted to point out that makefile for MSVC (and possibly other makefiles, I didn't check) are incompatible with make-3.81. Version 3.80 works. `make' says : "makefile.vc:258: *** target pattern contains no `%'. Stop."

I think it needs to be fixed before 4.2.1 is released because everyone will start using 3.81 soon.

Makefile for unix is fine.

Sure. Do you have a fix?
I won't be looking into this (no time).

I tried to fix it but makefile concept it too repulsive for me. No success.

What is in that line?

It complains about lines starting with $(WINDIR_U) and $(MSVCDIR_U).

The variables are empty then. I have seen that happen when MINGDIR is not defined. Apparently the makefile is detecting you have unix tools, thus using WINDIR_U instead of WINDIR_D, which is wrong. Do you have sh.exe in your path?

Shouldn't it abort with a warning or error in that case? Or is that just for the MinGW port?

That's not the case. UNIX_TOOLS is actually not defined. None of the variables seems to be empty. I even tried to replace variables with values they are supposed to contain and the same error appeared. And as I said, with make-3.80 works fine.

Ok, so the question is: is this a problem with Allegro's Makefile, or is it a bug in the newer version of make? It starts to sound like the latter, to be honest...

Does the same problem show up with GNU make 3.81 on other platforms, or just with the MinGW version?

I'm using cygwin's make. It fails with the same error on makefile.vc and makefile.mgw.

Yep, it seems to be the problem with the cygwin port of make.
http://lists.gnu.org/archive/html/bug-make/2006-07/msg00018.html
I'll see if I can work around it.

Ok, in that case I say we document that Cygwin's make 3.81 is broken and tell people to complain to them about it.
I honestly don't want to try dodgy workarounds that may break other platforms.

I agree. I couldn't find a easy way around it. It is still possible that the issue will be fixed in a patched release versioned like 3.81-2 or something... And I'm quite sure it will be fixed in the next release because I saw some patches in make CVS that enable DOS path support in cygwin build of make.