[AD] [ alleg-Bugs-1755144 ] Allegro compilation dies with MinGW W32API 3.9

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]

Bugs item #1755144, was opened at 2007-07-17 07:55
Message generated for change (Comment added) made by tjaden
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Gary F (dinosaur12)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allegro compilation dies with MinGW  W32API 3.9

Initial Comment:
I originally posted this to the MinGW API forum on SourceForge.  Since I solved the problem myself, I want to pass on the problem and a patch to the Allegro development team.  This problem did not show up in earlier versions of MinGW, just after the new Windows API released 3/26/2007.  The patch is inelegant (comment out Allegro code) but it works for me.  I'm sure the team can come up with better conditional code.

The original SourceForge post and reply:
Allegro library won't compile with API 3.9
By: Gary F (dinosaur12) - 2007-07-15 23:17
This is my first post to Sourceforge, so please excuse me if I am a little verbose to lay some background. I am not a newbie to MinGW -- I have successfully used Dev-Cpp (IDE which includes MinGW/gcc 3.4.2) to compile hundreds of programs, mostly console, some simple Windows style. I have some experience downloading source library packages and compiling them either directly with Dev-Cpp/MinGW or by using MSYS. I am a big fan of MinGW and hope the project continues. 
I have kept up with the MinGW updates and have successfully updated by copying the binaries (and libs and includes, etc.) to the Dev-Cpp folder. This usually has been successful, and I have repeatedly tested the compilations and resulting executables to verify functionality of the updates. 
I recently got around to trying out the updates to the the Windows API (3.9) and mingw runtime (3.12), both posted for download 3-26-2007. I copied the new i386 binaries, libs, includes, etc. to overwrite the originals. I subsequently successfully recompiled many, many programs with the new files and thought everything was fine until I tried to recompile the Allegro game library 4.21 (www.talula.demon.co.uk/allegro/). This had easily compiled many times before in various Allegro and MinGW versions. This time the compile crashed, apparently in some module dealing with Windows media code (WAVEFORMATEX???). None of my personal code dealt with this realm, so it had not triggered the error. I have confirmed by experiment that it is something in the API update that triggers the compile crash.  
I have yet to dig through the code to extract a short, specific example to prove the point, but I suspect other Allegro users (there are many, I think) might have seen this problem already. I will try to follow up with a code example in a later post. I suspect a deprecated function or type definition may have killed the compile. I plan to revert to my prior MinGW environment until the problem is resolved.  
I would like answers to two related questions about using a hybrid of update packages: 
1) Is w32api-3.9 tied inextricably to mingw-runtime-3.12 -- that is, does the API expect the new runtime to be present? 
2) May the 3.12 runtime update be successfully used with older versions of the API (that is, is API 3.9 the only update to avoid for now)? 


      RE: Allegro library won't compile with API 3.
      By: Gary F (dinosaur12) - 2007-07-16 17:34
      I am answering my own post. 
      After splitting the problem down into smaller parts, I identified the offending code and the conflict with w32api-3.9. I decided to attack the problem by patching the Allegro code instead of the w32api-3.9 code. I will copy this thread to the Allegro library developers so they can decide what to do in future releases. 
      Basically, there was a change in w32api-3.9 to mmsystem.h which conflicted with some Allegro code (in Allegro's almingw32.h). The effect was to try to build conflicting definitions for WAVEFORMATEX (Directsound functionality, apparently), which killed the compile when the new library was included. I don't know anything about the details of the definitions or the use of the functions, but I figured MinGW probably had it right, so I patched (inelegantly) the Allegro code by commenting out the offending redefinition. The code compiled cleanly after that, and all tests appear successful. 
      Sorry for stirring up the API team for an external problem, but others might need to know the solution. 
      The patched code in Allegro's almingw32.h: 
      /* PATCH 7/16/2007 GLF -- MinGW winAPI 3.9 or later breaks the following and  
      /* already defined... */ 
      /* ----------- begn patched code 7/16/2007 GLF (comment out) ---------------- 
      ----------- end patched code ------------------------------------------------ */ 



>Comment By: Peter Wang (tjaden)
Date: 2007-07-17 09:28

Logged In: YES 
Originator: NO

Thanks. It was fixed a few months ago in the Subversion repository, so it
will appear in 4.2.2. I don't the answers to your other questions.


You can respond by visiting: 

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/