Allegro.cc Forums » Installation, Setup & Configuration » Allegro build problem on windows 10

Credits go to Peter Hull and Polybios for helping out!
 This thread is locked; no one can reply to it. 1   2
 Allegro build problem on windows 10
 Mitch Randall Member #16,706 July 2017 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, 20171) 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-setupIt installed:mingw-developer-toolkit 2013072300mingw32-base 2013072200mingw32-gcc-g++ 5.3.0-3msys-base 20130723003) 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:\allegro6) run cmake-guiWhere is the source code: C:/allegroWhere to build the binaries: C:/allegroClick on ConfigureClick on Generate7) Then, in a command window, I cd\allegro and type makePROBLEM: 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.objc:/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 1make[1]: *** [CMakeFiles/allegro.dir/all] Error 2make: *** [all] Error 2For fun, I went into CmakeCache.txt and changed//Have function strerror_sALLEGRO_HAVE_STRERROR_S:INTERNAL=1to//Have function strerror_sALLEGRO_HAVE_STRERROR_S:INTERNAL=Then it was able to get past the compile of file_stdio.cBut then it had dozens of errors because[ 13%] Building C object CMakeFiles/allegro.dir/src/win/whapxi.c.objIn 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!
 Polybios Member #12,293 October 2010 Where did you get MingW from? The versions seem to be a bit dated.I'd recommend trying out MSYS2. I've written/updated the tutorial about it here. (Btw., maybe someone with access to the Wiki might be so kind as to merge it.)
 Edgar Reynaldo Member #8,592 May 2007 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_BinariesAll 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.
 bamccaig Member #7,536 July 2006 Would it be possible to write a batch script to automate the collection and building of Windows dependencies? I believe that an important role of free software is making it easy to build from source so that users of it can trust that there are no hidden instructions in their code (not that every user audits it, but if any user audits it, they can find it). I imagine with at least MSYS you must have enough tools at your disposal to automate the process of collecting dependencies. I'd be willing to try to put one together if somebody could lay out the steps required and work with me to work out the kinks.Binaries are nice, but a text-based solution is always nicer in a free world. -- I mean the best with what I say. It doesn't always sound that way.
 Edgar Reynaldo Member #8,592 May 2007 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.@PolybiosA gmail account won't kill you. :/ Especially a fake temporary one.
 bamccaig Member #7,536 July 2006 If you can note down each step I would be willing to attempt to script it. I lean towards batch only because I've spent a good deal of time learning it for Windows compatibility, but in this case I guess we'll always have (and depend) on at least parts of MinGW/MSYS so it might be best to use bash. Whatever. There should be no reason we can't automate every step of the process. We can patch dependencies as necessary using MinGW or MSYS patch(1). The only concern is the maintenance cost to keep it working as dependencies change. But having a starting point is always the first step. If we can't maintain it going forward then we'll have learned a few things and not much else, but if we can maintain it going forward then users that request build instructions can be shown the shell program we output: that will tell them everything need to do, and if they trust us they can just run it. -- I mean the best with what I say. It doesn't always sound that way.
 Edgar Reynaldo Member #8,592 May 2007 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 Randall Member #16,706 July 2017 This reply is specifically to Polybios:I followed the "here" link in your above post to go to your installation tutorial.I brought my machine to a clean state by removing cmake, mingw, and the allegro source.Your instructions worked flawlessly up to number 5. I installed MSYS2, ran all of the pacman commands, etc. it was flawless.At number III) B) 5) is where it is time to run cmake and then compile the allegro library. (Remember, I have been building and using allegro since the 90's on DOS and windows platforms). Here's what happens:test@DESKTOP-NUKJ96A MINGW64 /c/build\$ cmake G"MSYS Makefiles" -D"CMAKE_SYSTEM_PREFIX_PATH:PATH=/mingw64/x86_64-w64-mingw32" -DWANT_MONOLITH=on ../allegro-- Building for: NMake Makefiles-- The C compiler identification is unknown-- The CXX compiler identification is unknownCMake Error at CMakeLists.txt:17 (project): The CMAKE_C_COMPILER: cl is not a full path and was not found in the PATH. To use the NMake generator with Visual C++, cmake must be run from a shell that can use the compiler cl from the command line. This environment is unable to invoke the cl compiler. To fix this problem, run cmake from the Visual Studio Command Prompt (vcvarsall.bat). Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH.CMake Error at CMakeLists.txt:17 (proj..... (there is another page of error description)Polybios: Your tutorial was flawless, well written, and easy. I now have the 64 bit and newer version of MSYS2, and a 64 bit MinGW. But at that step III) B) 5), something went afoul. Cmake doesn't seem able to find the compiler within the environment.If I type gcc, make, grep, cmake,... it all runs from the msys shell, so I know that the path environment is set up okay.The computer I am using is literally right out of the box. The only thing I did to it was install DirectX and then attempt to get allegro working.Thanks for your help so far, and thanks in advance for any help you can give. As I say, I compiled allegro 5.2.2 on my windows 7 machine. I just can't get it to compile on either of two brand new win10 machines.
 Peter Hull Member #1,136 March 2001 Mitch,Did you actually put Mitch Randall said: cmake G"MSYS Makefiles" ... or Quote: cmake -G"MSYS Makefiles" ...because if it's looking for NMake and cl, that's Visual C++ stuff.PeteI 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.
 Mitch Randall Member #16,706 July 2017 Peter and Polybios, Thank you Peter for the catch! I MISSED THE '-' in front of the G!!!! Now allegro built perfectly! Thank you Polybios for the step-by-step installation guide. I can vouch that it works perfectly. I recommend anyone attempting to get allegro on a new machine to follow Polybios' link above.
 Neil Roy Member #2,229 April 2002 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.  --Deluxe Pacman (website now gone)"I am not ashamed of my belief in God."
 Edgar Reynaldo Member #8,592 May 2007 You can use "Unix Makefiles" or "MinGW Makefiles", depending on which environment you're using. Type cmake -h at the command line to see a list of available generators on your platform.
 Polybios Member #12,293 October 2010 Glad that it worked, Mitch.Neil Roy said: Not surprisingly, following the wiki instructions leads to a problem. 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.Edgar Reynaldo said:A gmail account won't kill you. :/ Especially a fake temporary one. Not gonna happen, sorry.
 Edgar Reynaldo Member #8,592 May 2007 So it's okay for us to sell our souls to Google and edit the wiki for you, but it's not okay for you. That's cool.
 Neil Roy Member #2,229 April 2002 Polybios said: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. 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. --Deluxe Pacman (website now gone)"I am not ashamed of my belief in God."
 bamccaig Member #7,536 July 2006 You can always open a console window and reset the PATH variable to a base setting to test if your executables are linking to any unexpected libraries:set PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem path\to\game.exe That is apparently Windows 7's default PATH, but you can Google to find the right setting for your exact OS. Or you can backup the PATH you have now into a separate variable MY_OLD_PATH or something. Restore the path for a console window and try to run your game.Note: Setting the variable in a console only affects that console and new child processes. To have a variable persist forever you need to edit it in the registry or use the environment variable GUI.Having DLLs in the PATH is a necessary evil in Windows to have the convenience to use the command line without having to type paths or cd all the time. It defeats the purpose entirely if you can't just type "command arg..." -- I mean the best with what I say. It doesn't always sound that way.
 Edgar Reynaldo Member #8,592 May 2007 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.
Polybios
Member #12,293
October 2010

Let's try to clear a few things up a bit.

First, you'll always have to have some DLLs on the path if you want to run your binaries "normally" outside your IDE, won't you? Unless you build everything statically.

Second, MSYS2 is package management for Windows. Every library package you install through MSYS2's pacman will contain shared libraries, likely depending on other shared libraries from other packages.
This is by design and it's probably the only way to sanely implement such a system. So if you install libraries through pacman, there will be DLLs.
However, the compilers work just normally, so binaries produced with the usual -static... options will not depend on anything unusual or msys2-specific. So it's absolutely fine to use it for building.[1].
But: If you want to limit the DLL dependencies of your Allegro DLLs, you have to build all the Allegro dependencies yourself, the versions from MSYS2-packages won't do.[2]

Well not quite: Fear not, the great SiegeLord has made the allegro_winpkg project: The dependencies are bundled together in one repository and ready to be turned into static libraries by the scripts accompanying them. There are also scripts to build several flavors of Allegro binaries themselves.[3], using exactly these statically built dependencies. You can also download ready-made versions of Allegro and/or dependencies' static libraries for MSYS2 from http://liballeg.org/download.html (i.e. the results of using allegro_winpkg). However, MSYS compiler versions increase more quickly than Allegro versions, so these might not always be compatible.

Now, what to use?
My personal opinion is the following: For getting into Allegro5 development on Windows, using MSYS2-presupplied packages (they do provide Allegro5 themselves) is probably easiest (if MSVC + Nuget packages are not an option). For anything else, especially distribution (if you ever get there), compile your own binaries from allegro_winpkg, at least use it to compile static libs of the dependencies and then compile Allegro5 yourself with these.

One last thing: "This was all easier with A4"? Not quite. Most of the complications arise from the dependencies for addons for which A4 had no equivalent functionality (ttf fonts, video, mod files, jpeg/png loading, audio codecs, native dialogs, ...). Everyone is free to build Allegro5 without these addons and it will result in less hassle, but also less functionality.

## References

1. There's a difference between mingw-w64- and MSYS2 toolchains. The latter will produce binaries that need msys-2.0.dll
2. You could try to remove all dll.a files, because they do seem to ship some static libraries, but it doesn't seem to work reliably.