I am not able to get allegro 5.2.2 to build on windows 10 machines. I've tried two. I have been using allegro on other windows versions for years.

Here's what I did starting with two clean windows 10 machines.

Today's date: July 11, 2017
1) Installed MS DirectX SDK.
(I had to unistall MSVC++ back to 2010 because of error S1023 - a well documented issue)

2) Installed MinGW using mingw-get-setup
It installed:
mingw-developer-toolkit 2013072300
mingw32-base 2013072200
mingw32-gcc-g++ 5.3.0-3
msys-base 2013072300

3) Added c:\MinGW\bin;c:\MinGw\MSYS\1.0\bin;c:\MinGW\MSYS\1.0\local\bin to the user path. Tested that make and grep etc. were available from a cmd window.

4) Installed cmake latest version 3.8.2 (cmake-3.8.2-win64-x64.ins)

5) Got the latest allegro source allegro-5.2.2.zip. Unzipped it to create c:\allegro

6) run cmake-gui
Where is the source code: C:/allegro
Where to build the binaries: C:/allegro
Click on Configure
Click on Generate

7) Then, in a command window, I cd\allegro and type make

PROBLEM:

With both computers (an ASUS running win10, and an HP running win10) I get a compile after about 20 source files compile:

[ 5%] Building C object CMakeFiles/allegro.dir/src/file_stdio.c.obj
c:/allegro/src/file_stdio.c: In function 'file_stdio_ferrmsg':
c:/allegro/src/file_stdio.c:302:7: error: unknown type name 'errno_t'
errno_t rc = strerror_s(userdata->errmsg, sizeof(userdata->errmsg),
^
make[2]: *** [CMakeFiles/allegro.dir/src/file_stdio.c.obj] Error 1
make[1]: *** [CMakeFiles/allegro.dir/all] Error 2
make: *** [all] Error 2

For fun, I went into CmakeCache.txt and changed

//Have function strerror_s
ALLEGRO_HAVE_STRERROR_S:INTERNAL=1

to

//Have function strerror_s
ALLEGRO_HAVE_STRERROR_S:INTERNAL=

Then it was able to get past the compile of file_stdio.c

But then it had dozens of errors because

[ 13%] Building C object CMakeFiles/allegro.dir/src/win/whapxi.c.obj
In file included from c:/allegro/src/win/whapxi.c:67:0:
C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/Include/xinput.h:231:5: error: unknown type name '__in'
__in DWORD dwUserIndex, // Index of the gamer associated with the device
^
C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/Include/xinput.h:232:5: error: unknown type name '__out'
__out XINPUT_STATE* pState // Receives the current state
^
C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/Include/xinput.h:237:5: error: unknown type name '__in'
__in DWORD dwUserIndex, // Index of the gamer associated with the device
^

and on and on and on.......

Can anyone experienced with this recognize what is going on? What is wrong?

Help!

You don't need MSYS2 for MinGW, and mingw.org is outdated. They are stuck on gcc version 5 and have lots of other problems as well.

You can use my binaries for MinGW if you like. You can find them here :
https://wiki.allegro.cc/index.php?title=Unofficial_MinGW_Binaries

All you need to do is unpack the archives, put them somewhere you like, add your mingw\bin folder to the path, and compile away.

My binaries come with all the dependencies prepackaged. No need to build anything yourself.

If you do want to build allegro yourself with mingw, you will have some problems. The DXSDK needs sal.h, which is provided on liballeg.org. MinGW-w64 comes with a full set of direct x headers and libraries so the SDK is not needed.

Your problem with HAVE_STRERROR_S stems from mingw.org being outdated. They don't have all the functions necessary, so you have to manually fiddle with things like you found out.

My recommendation is to use MinGW-W64, regardless of whether or not you build it yourself. Be aware that the compiler version has to match the version used to build allegro and its dependencies.

Writing a build script for Windows would be somewhat difficult I think, given my experience building all the dependencies. SiegeLord himself made cmake scripts to build each dependency, but that's not strictly necessary, as my binaries show. I built everything directly with either cmake or MSYS and autotools, using a mingw-w64 compiler. However, I did have to patch physfs and theora to get them to build properly. I don't know if the changes will ever make it upstream though.

Maybe next time a new version of Allegro comes out I will document the steps taken to build everything. It takes a decent while to do, but once the deps are built there's (usually) no reason to rebuild them ever again.

But I agree, building on Windows is in desperate need of some kind of automation. I would be willing to help you with this in my spare time if you want bamccaig.

@Polybios
A gmail account won't kill you. :/ Especially a fake temporary one.

I probably won't have any time to work on this until the weekend, and perhaps a few more days to get me caught up with the rest of my responsibilities.

Changing everything from a cmake-gui configuration that I use into a cmake command line config may be problematic, especially for allegro. There are a ton of things to configure and it might be hard to do in a single command line.

I suppose curl could be used to gather dependencies and place them into their own folder. Create a build folder and run cmake/configure.

If SiegeLord contributed his cmake scripts, it might go a long way towards accomplishing this.

Mitch,
Did you actually put

or

because if it's looking for NMake and cl, that's Visual C++ stuff.

Pete

[edit]
I had a try myself (Windows 10, 64-bit). Following the instructions on the wiki I was able to build Allegro and run the examples. I didn't try anything more ambitious than that, though.

These days I mostly use Linux; if I'm on Windows I use Visual Studio and the NuGets.

[edit2]
I got MSYS2 from http://www.msys2.org/ , not what the wiki says. Apart from that I followed the instructions.

I decided to give it a go and try to compile Allegro again for myself. Not surprisingly, following the wiki instructions leads to a problem.

Following all instructions to the letter, I get this when I try the cmake part.

cmake -G"MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=/mingw64/x86_64-w64-mingw32 -DWANT_MONOLITH=on ..

CMake Error: Could not create named generator MSYS Makefiles

Generators
  Unix Makefiles               = Generates standard UNIX makefiles.
  Ninja                        = Generates build.ninja files.
  CodeBlocks - Ninja           = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - Ninja             = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
  KDevelop3                    = Generates KDevelop 3 project files.
  KDevelop3 - Unix Makefiles   = Generates KDevelop 3 project files.
  Kate - Ninja                 = Generates Kate project files.
  Kate - Unix Makefiles        = Generates Kate project files.
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files.

Glad that it worked, Mitch.

Well, that's exactly why I updated the article in the thread referenced above. Unfortunately, I couldn't edit the wiki at the time and still can't.

Not gonna happen, sorry.

I'll check that out. I followed a reference already, didn't see a second one. If I ever get this sucker compiled I am awarding myself with something.

Edit: Nevermind, just noticed the "compile it yourself" part, , that's what happens whan I go to the bathroom between reading... gonna try that now.

Remove the MSYS2-supplied package if installed 

Making me do extra work!

Edit2: Compiling now. Never really used MSYS before, starting to wish I had. Nice system. The following advice you give makes me nervous...

"When you want to run programs build with MSYS2 outside your terminal window, your system needs to be able to find the DLLs that reside in /mingw64/bin (for a 64 bit installation). So you'll need to add C:\msys64\mingw64\bin to your system PATH if C:\msys64 is where you installed msys2. You should take care that no other similar installation is on the path before this one. "

...I don't think it is a good idea to have DLLs in your path. Not when developing anyhow. It leads to problems like what Edgar had, when you compile something that is static, but accidentally require a DLL. You won't catch that problem if your DLLs are in your path. I purposely leave all my DLLs out of my path for projects I am developing for, this way if I need a DLL, I will know if I did not include it with the binary, or if it is static, I will know if it needs a DLL. Instead I copy the DLLs needed into the same folder as my executable. This is good as once it works, I know what DLLs to include etc... I just include everything in that folder.

There should at least be a warning about this if you ever intend to add this to the WIKI as it can be a hard to spot gotcha.

From a command console, enter a new session by typing cmd. Then type 'set path='. This will remove the path variable entirely from the session. Then cd to your game's folder and run it. That will make sure it is using strictly the directory it is in to look for dlls. When you're done, just 'exit' the session and you'll be restored to your regular environment. Voila.

If building with MSYS2 means you depend on dlls from the mingw\bin folder, there's something wrong. All you should need is the c and c++ std libraries unless you linked those statically too.

You left out a few things. win_pkg uses older versions of the dependencies, and SiegeLord said it would be somewhat difficult to update them. My binaries include ALL static versions of the dependencies. It would be FAR easier to use my binaries then build allegro yourself. And MSYS2 is not necessary, and introduces further dependencies on the MSYS2 runtime itself. You can build directly with MinGW-w64 with absolutely no need of MSYS2. Sometimes you need MSYS to run configure because they didn't ship cmake scripts but whatever. If you build all the libraries yourself you don't have these problems, which is what I did.

Also, I would be very surprised if msys2's repository includes a version of allegro 5 that is actually RECENT.

I'll stick to Edgar's builds, thanks. He does a nice job. Figuring out all the ins and outs of building this is just not my thing and quite frankly, turns me off of programming entirely.

This does illustrate the problems with this version of Allegro 5, as much as I like it, and I DO like it, it's awesome! It's just a maze of ridiculous hoops to jump through to compile it yourself. I'm happy to help Edgar locate problems with his builds and get them working, seems like a better use of my time.

Nice work Edgar, this only gives me more respect for your talents.

This is an update (sadly)....

I thought I was out of the water when allegro compiled following Polybios' step-by-step tutorial near the top of this thread. But....

I was unable to run programs because some entry point or something was wrong....

Not satisfied, I wasted two days figuring out what my problem really was. After all, I just compiled the allegro source on a win7 machine a few days ago flawlessly, here is the answer to my own question: How to install allegro 5.2.2 on a brand new, clean win10 machine:

1) Uninstall any MSVC++ redistributable back to before version 2010. (This prevents error s1023 - a well documented error with step 2)

2) Install DirectX from microsoft's official site.

3) Install mingw (mingw-get-setup.exe) from the mingw.org site. This is the older 32 bit version, but this is what worked for me. Install Choose everything but ada, objectivec, and fortran from the "basic setup" tab.

3.5) Add c:\mingw\bin and c:\mingw\msys\1.0\bin to the local system path by going to windows "system" (in control panel) and then clicking on "advanced settings" then clicking on "environment variables". This will keep the path any time you open a cmd window.

4) Install cmake (cmake-3.8.2-win64-x64.msi)

5) Get allegro-5.2.2.zip from http://liballeg.org/download.html . Unzip it into c:\ so that you end up with an allegro directory in the root c drive.

6) Also pull down sal.h at the bottom of the http://liballeg.org/download.html page. Put it in C:\MinGW\include. It turns out this is the file I was missing all along that allows allegro source to compile with DirectX, which is required.

7) Run cmake-gui.
a) Where is the source code: C:\allegro
b) Where to build the binaries: C:\allegro
c) Click on Configure - it makes a bunch of red statements
d) Change WANT MONOLITH to have a checkmark
e) Click on Configure again. All of the red should go away.
f) Click on Generate
g) exit Cmake.

7) Now edit into C:\allegro\cmakecache.txt
a) search on strerror_s
b) change to read:
//Have function strerror_r
ALLEGRO_HAVE_STRERROR_R:INTERNAL=
//Have function strerror_s
ALLEGRO_HAVE_STRERROR_S:INTERNAL=

This solves the problem that kills the compile at about 4% into it.
I think this is something that needs to be fixed, because after I run cmake, these values are set to 1, but then during compile there is an error because strerror is undefined. So something about the Cmake function that determines if strerror is defined is wrong.

8) in a dos cmd window, go to c:\allegro and type:
make

9) type
make install

10) Finally, I added c:\allegro\lib into my local path environment variable so that I can run programs from any directory without worrying about the monolith .dll file.

So, in conclusion, the old mingw is perfectly adequate to compile the allegro5 source code, but there are two issues:
1) sal.h must be moved into the mingw\include directory, and
2) you have to fool the system into knowing that strerror is NOT defined.

Note also that there are numerous threads from the past that discuss the old problem that sal.h is needed to compile and resolve DirectX __in and __out missing items. And there are also threads about the known problem of the strerror_s!!!!

I hope this helps people in the future who just want to get their old, familiar allegro up and running on a win10 machine!!!

Thanks to everyone for all your great support and help. I love allegro, and I love the great community of people that have put so much into this!!!!!!

Thanks everybody for the help.

@Mitch

I told you you would have problems if you used old mingw and the DXSDK. Do NOT uninstall your MSVC runtimes. Programs will stop working. The DXSDK from Jun 2010 works if you use sal.h from liballeg.org. But it's a MASSIVE download, and the most recent version of DX now comes with the Windows SDK, which is even more massive. mingw claims to have POSIX support, but it's spotty at best, and there are unimplemented standard functions and structs, which is unacceptable if you want to live in the real world and use a modern version of C or C++.

I've done the exact same thing as you to get my binaries to build in the past.

That is the EXACT reason I said to use MinGW-W64. They provide binary distributions of their compiler that you can just plop into place and compile with. They COME with DX headers, libs, and work perfectly with the DirectX 9, 10, and 11 runtimes that people have installed on their computers.

See https://sourceforge.net/projects/mingw-w64/files/ for downloads (scroll down to the links).

PLUS, the most recent version of gcc supported by vanilla mingw.org is 5.3. That is ANCIENT. It can't even properly compile (much less support) C++11. The version of the compiler that I used is made for gcc version 7.1, and 8 will be out in the near future. Full support for C++11,14,17 etc...

See https://wiki.allegro.cc/index.php?title=Installing_MinGW for details.