Hello there a.cc community.

Thanks to the fine Elias, there is finally a guide to compile Allegro from sources on Windows using the MSYS2 shell and a recent mingw-w64 gcc.

You can find that on the wiki here.

This should be a very QUICK (and easy?) method to get allegro built on Windows, that seems oh-so-much-needed

Please if anybody interested can peer-review and give feedback, that would be great.

NOW, I'm definitely boiled...g'nite everyone.

Wow, msys2 uses a port of pacman? That's a golden idea. Now installing dev packages on Windows will be as easy as it is on Linux!

cmake \
	-G"MSYS Makefiles" \
	-DCMAKE_SYSTEM_PREFIX_PATH=/mingw64/x86_64-w64-mingw32/
	-DWANT_MONOLITH=on \
	-DSHARED=off \
	../allegro

I have to confirm this, as I tried in a new MSYS2 and the command proposed by Elias does not work for me, while this proposed one does.

I'll edit the wiki but it would be nice for an outsider to test it on a clean slate

I thikn I'll steal also some info on git and build options from Siegelord's guide,

You wish! anyway it's quite manageable do write down your build recipe (PKGBUILD), I know I did this for the Freetype library when the 'stock' one used harfbuzz and a bunch of other things...

No, change to yours, and I'll try it next time I'm in windows. I didn't install the mingw64 tool chain I think, but instead had some msys2 packages, so that may explain. What error did you get?

I tried it and got this

pepsi@microcrap ~
$ pacman -S mingw-w64-x86_64-theora
error: target not found: mingw-w64-x86_64-theora

so I googled just a few seconds and tried 'mingw-w64-x86_64-libtheora' and it said something about SDL!

That's because the Theora example program is based on SDL 1.2 and that is by default inclided in the libteoradec package.

It didn't find DINPUT, and that has been as always...there's also a thread buired somewhere on a.cc....

So the wiki should be changed to say "pacman -S mingw-w64-x86_64-libtheora"?

It should, yes , ehm whoopsie.

That's why I had the library path in mine, but I might have had a different win32api package? For me it is in /usr/lib/w32api/libdinput.a.

It might depend on your compiler, all mingw builds flavors have different layouts depending on the "target".

TDM-gcc for example didn't need ANY hint to cmake to find DINPUT, when I tried it.

EDIT: I might add, libdinput.a is in /mingw64/x86_64-w64-mingw32/ in the MSYS2 compiled toolchain I used for the wiki.

So I should use mingw-w64-i686-toolchain instead? Why is it w64? I installed the 32 bit version of MSYS2. Should I use something else instead?

That's perfectly okay Edgar, you can use 32bits version of of MSYS and that should download the right toolchain as far as I am aware.

Mingw-w64 is so called to distingiush it from the "original" mingw from which it is clearly separated for all the good reasons (developers diverging for some reason).

The 'w64' should not scare you out, that CRT is perfectly tuned for a native 32-bit system, whichi is mingw32 in all cases

In fact the '-dumpmachine' for the two gcc is:

$ gcc -dumpmachine
x86_64-w64-mingw32

for the 64-bit flavor of gcc and

$ gcc -dumpmachine
i686-w64-mingw32

for the 32-bit one.

Okay, got everything installed, but haven't built allegro yet with MSYS2. Installation of all those packages was a breeze!

How do I search for a package with pacman?

Also, cmake worked fine in MSYS2 but mingw32-make does not, and make is not installed. Here's the error (It's searching for the other cmake I have installed outside of MSYS for some reason) :

Try the regex expression Search

pacman -Ss <regex>

for example

$ pacman -Ss theora
mingw32/mingw-w64-i686-libtheora 1.1.1-1 [installato]
    An open video codec developed by the Xiph.org (mingw-w64)
mingw64/mingw-w64-x86_64-libtheora 1.1.1-1 [installato]
    An open video codec developed by the Xiph.org (mingw-w64)

while, to search for GROUPS you do

pacman -Sg

and to look the packages in a specific GROUP

pacman -Sg <groupname>

for example:

$ pacman -Sg VCS
VCS git
VCS mercurial
VCS subversion

That is okay, since you have to run native MSYS2 make, mingw32-make would not work.

it's strange make is not installed, it SHOULD have been in the mingw-w64-<arch>-toolchain.

In mine:

$ pacman -Sg mingw-w64-x86_64-toolchain
mingw-w64-x86_64-toolchain mingw-w64-x86_64-binutils
mingw-w64-x86_64-toolchain mingw-w64-x86_64-crt-svn
mingw-w64-x86_64-toolchain mingw-w64-x86_64-gcc
mingw-w64-x86_64-toolchain mingw-w64-x86_64-gcc-ada
mingw-w64-x86_64-toolchain mingw-w64-x86_64-gcc-fortran
mingw-w64-x86_64-toolchain mingw-w64-x86_64-gcc-libgfortran
mingw-w64-x86_64-toolchain mingw-w64-x86_64-gcc-libs
mingw-w64-x86_64-toolchain mingw-w64-x86_64-gcc-objc
mingw-w64-x86_64-toolchain mingw-w64-x86_64-gdb
mingw-w64-x86_64-toolchain mingw-w64-x86_64-headers-svn
mingw-w64-x86_64-toolchain mingw-w64-x86_64-libmangle-svn
mingw-w64-x86_64-toolchain mingw-w64-x86_64-libwinpthread-svn
** mingw-w64-x86_64-toolchain mingw-w64-x86_64-make **
mingw-w64-x86_64-toolchain mingw-w64-x86_64-tools-svn
mingw-w64-x86_64-toolchain mingw-w64-x86_64-winpthreads-svn

and

$ pacman -Sg mingw-w64-i686-toolchain
mingw-w64-i686-toolchain mingw-w64-i686-binutils
mingw-w64-i686-toolchain mingw-w64-i686-crt-svn
mingw-w64-i686-toolchain mingw-w64-i686-gcc
mingw-w64-i686-toolchain mingw-w64-i686-gcc-ada
mingw-w64-i686-toolchain mingw-w64-i686-gcc-fortran
mingw-w64-i686-toolchain mingw-w64-i686-gcc-libgfortran
mingw-w64-i686-toolchain mingw-w64-i686-gcc-libs
mingw-w64-i686-toolchain mingw-w64-i686-gcc-objc
mingw-w64-i686-toolchain mingw-w64-i686-gdb
mingw-w64-i686-toolchain mingw-w64-i686-headers-svn
mingw-w64-i686-toolchain mingw-w64-i686-libmangle-svn
mingw-w64-i686-toolchain mingw-w64-i686-libwinpthread-svn
** mingw-w64-i686-toolchain mingw-w64-i686-make **
mingw-w64-i686-toolchain mingw-w64-i686-tools-svn
mingw-w64-i686-toolchain mingw-w64-i686-winpthreads-svn

(emphasis mine)

Try to look for make and in case just 'pacman -S' it, worse can happen is asking you to reinstall the same package.

"native" MSYS2 make should look into MSYS2 PATH that should contain your cmake-git.

Care that you have to pass '*-G"MSYS Makefiles"*' to cmake and NOT MinGW, thou cmake itslef should warn you about that having 'sh' in your PATH.

EDIT(s): tried to straightn up vertical spacing...unsuccessfully

I installed mingw-w64-i686-make again but it still says

-bash: make: command not found

Is it called something else?

And just for comparison I just got done manually downloading mingw 4.8.1-4 and it took me like an hour to get everything downloaded and unpacked where I spent like 10 minutes on MSYS2 and I still don't have the dependencies for allegro downloaded and built with mingw 4.8.1 yet. That will probably take like another couple hours at least.

Edit
It's installed alright :

$ pacman -Ss make
...
mingw32/mingw-w64-i686-make 4.0.2289.432cb65-1 (mingw-w64-i686-toolchain) [installed]
    GNU make utility to maintain groups of programs
...

Often the mingw make isnt called "make" but "mingw32-make" iirc. it might even be worse with the new msys? maybe it's called: mingw-w64-i686-make on your setup.

I think my PATH in MSYS2 is broken somehow, but I don't know how to fix it. It must be trying to use mingw32-make from c:\mingw instead of /usr/bin, but /usr/bin is first in the PATH in MSYS2, and it tries to run the cmake installed outside of MSYS as well :

$ mingw32-make
process_begin: CreateProcess(NULL, /C/downloads/Programming/CompilingTools/CMake2.8.12/bin/cmake.exe -H/C/MSYS2/msys32/home/Edgar/a5git/allegro -B/C/MSYS2/msys32/home/Edgar/a5git/allegro/build --check-build-system CMakeFiles/Makefile.cmake 0, ...) failed.
make (e=3): The system cannot find the path specified.
mingw32-make: *** [cmake_check_build_system] Error 3

It shouldn't be, it is make on mine:

$ where make
C:\msys2\bin\make.exe

but of course there also is Mingw32-make

$ where mingw32-make
C:\msys2\mingw64\bin\mingw32-make.exe

to be used outside MSYS.

That's the most likely explanation, it could be because you have those in your Windows PATH, thou I am not sure. Could you pls paste the MSYS2 path here?

also try

$ which make

to identify WHICH make it is launching

In any case DO NOT use mingw32-make as it won't work...at least AFAIK.

EDIT: also, which bat file are you using to launch the MSYS2 env?

Okay, so I have been starting the msys_shell.bat file - I suppose that was wrong. I started the mingw32 batch file instead, and now it recognizes mingw32-make and doesn't bork out with the wrong cmake. However it now fails when trying to build allegro because it can't find FLAC/stream_decoder.h, and it is not in /usr/include - there are only like 4 files in there! Where does MSYS2 keep it's include files?
FLAC is installed, I checked.

Are you still using minw32-make? In that case DON'T, you have to use regular 'make'.

The lib, bin and includes are kept in '*/mingw32/i686-w64-mingw32/*' but you should have passed that to cmake as '*-DCMAKE_SYSTEM_PREFIX_PATH:PATH=/mingw32/i686-w64-mingw32/*' otherwise cmake should have booted you out early.

It can't find make. 'where make' comes up empty.

My old MSYS has make, but MSYS2 does not, even though it says it is installed.

Does Windows show any file named "make,exe" in the bin directory?

Try also which make

I now think I got it, would you please try:

pacman -Ss make

please?

you have to use MSYS make, while the one in the toolchain is indeed the mingw32-make

I think the wiki is due updating if so...

(Late) EDIT: that definitely needs to be updated.

You have either to install the 'base-devel' group or simply 'make' for msys which is..

pacman -S make

(Later) IMPORTANT EDIT:

I'm testing through it, and I spotted a thing I do not like.

Seems that GDI+ does not work in MSYS2 (cmake reporting SUPPORT_GDIPLUS - failed), while using this toolchain in QtCreator (meaning i generate the build files externally with a "windows" cmake-git and use MINGW makefiles) works.

Anybody experiencing the same?

I should add that mine built anyway because I have both libjpg and libpng (the former NOT passing the test JPEG_COMPILES due to clashing headers), and allegro gets built with all features.

Still being on windows and having a way to have it work (externally) makes me propend for faulty tests? I'll look into it but I'm not sure I'm qualified

(already asleep) EDIT:

Checked cmakerror.log, and says this:

The more sharp-eyed surely have spotted the DREADED:
collect2.exe: error: ld returned 5 exit status
which god knows what really means...usually that the linker ran out of memory....how could that be in THIS case? (!)

Anyway if I just try to manually compile on the command line that source REGARDLESS of how I define GDIPLUS_LOWERCASE, it compiles and link smoothly.

The same happens with JPEG_COMPILES test, ld returns exit status 5. I haven't bothered try out manually compiling, I'm quite sure that a VOID main should not have the linker run out of memory.

There's something fishy going on when cmake invokes g++ compiles INSIDE MSYS2...the g++ driver seems not to have this problem.

Naturally I couldn't replicate 100% the cmake command line as it is a bit convoluted and HUMANLY impossible, still the g++ driver should invoke ld just as well from the command line, no?

(Morning glory) EDIT: Cmake 2.8.9 is reported to work fine and has not ld throw a fit on SUPPORT_GDIPLUS, while both cmake (2.8.12.2) and cmake-git packages available on MSYS repos have this quirky behaviour

I'll have to sort out this in the wiki...as it stands the current guide "just works" (cmake detects at least libPNG and thus the library and the examples work correctly), but it's a stupid issue and I'd like to get a way to work around it...

Also, is there REALLY a bug somewhere?

EDITLESS: (this becam a bambam-y wall of text!)

I tried a very dumb thing, I downloaded the windows version of cmake from cmake.org, and placed it into MSYS2 root directory, and I pacman -R'd the MSYS2 cmake package.

Invoking the "windows" cmake instead of the MSYS one works perfectly, meaning GDIPLUS link test does not puke at me and NOW I think at least I know:

a) how to suggest a workaround for the guide in the wiki...
b) that it's the MSYS2 compiled cmake which actually has something worng with it.