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!

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?

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....

It should, yes , ehm whoopsie.

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.

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.

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

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.

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?

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.

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.