Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Old issue with sal.h, DXSDK, MinGW 5.3.03 and latest Allegro

Credits go to Elias and SiegeLord for helping out!
This thread is locked; no one can reply to it. rss feed Print
Old issue with sal.h, DXSDK, MinGW 5.3.03 and latest Allegro
Edgar Reynaldo
Major Reynaldo
May 2007
avatar

I posted this to the mingw-users mailing list a short while ago :

Quote:

Hello,

I'm currently trying to compile Allegro 5 with MinGW gcc 5.3.0.3 and the June 2010 DXSDK. I'm having several problems. The first is when compiling dsound.cpp, an allegro source file. It fails to compile because dsound.h includes sal.h, which doesn't exist in MinGW. The second is when trying to compile the XInput driver for allegro. It fails because xinput.h expects __in and __out function attributes to be defined.

My third issue is that MinGW seems to have some kind of minimal set of DirectX headers and libraries included (it looks like DX9 is there). Should I be using these instead? I don't see libd3dx9.a but that may be a Vista only extension. I think that is optional for one of the allegro examples.

My question is, what can or what should I do about all this? I just tried building allegro configured to use MinGW's DX and it fails to compile because dinput.h is missing. Direct Input is mandatory to build Allegro 5 on Windows. libdinput.a is included but the header is not for some reason.

I hope someone can offer me some insight on this. I really have no desire to move to MSYS2 and MinGW64 unless I have no other choice, but they work to build Allegro 5 without issues and I'm running out of options.

Thank you for whatever help you can offer, I appreciate it.

This issue has come up several times over the last several years. I thought it was fixed after this thread (https://www.allegro.cc/forums/thread/615359) but it's still there. I stopped using dx9mgw.zip because of licensing and incompatibility with system DX libraries and installed the DXSDK from June 2010. One workaround was to include sal.h from the "Allegro sourcepack" archive, which is supposed to be on the wiki but now gives a 404 error referenced by Trent from here (https://www.allegro.cc/forums/thread/614845/1007824#target). This bug has been around since 2013 at least as referenced by SiegeLord here (https://www.allegro.cc/forums/thread/612686/984613#target).

Anyway, I'm trying to build binaries for MinGW 5.3.0.3 and Allegro 5.2.2.GIT but this junk is getting in the way. I'll investigate further when I get the chance.

As it stands I can't build Allegro 5 with XInput support, or DSound either. And I can't use the DX that comes with MinGW because they don't include dinput.h in their distribution. They include libdinput.a but no header.

What a mess. Opinions? Fixes? Let's find a permanent solution to this once and for all. It shouldn't be this hard to build Allegro 5 with MinGW on Windows. I'll report back once I hear from the mingw-users mailing list about their opinion on this.

Edgar

Elias
Member #358
May 2000

Maybe you can find a way to extract the DX libraries from the msys2 package - that would be a quick and easy fix. (Uninstalling the Microsoft DXSDK first is probably a good idea.)

--
"Either help out or stop whining" - Evert

SiegeLord
Member #7,827
October 2006
avatar

Here's the link to the sourcepack... https://www.dropbox.com/s/rjhatfxy7p5bl1t/a5_sourcepack.zip?dl=0 Looks like Tomasu really broke the wiki :P.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

I haven't had the chance to test building Allegro with the sal.h included in that sourcepack, but I did look at sal.h. What the $##!%$? That thing is an abomination. Like 50 or more empty macro definitions? What does the real sal.h look like, and where does it come from? Is it included in the Windows SDK? I'll research it tonight, but I think it causes more problems than it solves.

According to someone on mingw-users, there are a couple open source DX distros on GitHub. I'll check them out and report back. Other options are to provide headers and import libraries for MinGW (who knows how much work that would be), or for MinGW to provide a real sal.h that isn't an empty waste of space. What are all those macros supposed to do anyway? And what happens if DX uses them and finds a null string in its place? Using sal.h is like asking for trouble to come home with you.

As for using MSYS2's DX headers and libraries, I have no idea which ones are necessary and which ones aren't, and I don't know whether they are compatible with vanilla MinGW either.

Regardless, dx9mgw.zip is totally broken and produces all kinds of crashes and bugs when running the DirectX driver. Either it should be removed, or replaced. As for sal.h, I hope there is a better alternative than what is provided in the source pack.

Edgar

SiegeLord
Member #7,827
October 2006
avatar

SAL is used to annotate C++ APIs for extra static analysis. In particular, the official DXSDK is full of such annotations. The real sal.h defines the annotations to some implementation specific bits, while the sal.h from the source pack defines them to nothing (since GCC doesn't support SAL), which seems to work fine in my experience.

The real sal.h indeed comes with Windows SDKs. The headers that come with MSYS2 have the SAL annotations removed manually.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Building allegro with the sal.h you provided and the June 2010 DXSDK works properly except for the issue with strerror_s. Keith Marshall has implemented strerror_r and strerror_s for the upcoming mingwrt-5 release so this issue will be fixed soon. Currently I fix the improper detection if strerror_s by manually editing Cmake ache.txt before building and after generating build files.

IMO, sal.h should be provided as a separate download on liballeg.org and should be documented as a build requirement for MinGW. I'm not sure how to go about editing liballeg.org but I can add this to the wiki once Tomasu fixes it.

Binaries should be available in the next day or so.

Edgar.

Go to: