MSYS2 build failures

[achadwick]

Experienced behavior

Current master does not build on MSYS2 as documented.

$ ninja
[1/67] Compiling c object src/graphene-1.0@sha/graphene-alloc.c.obj
FAILED: src/graphene-1.0@sha/graphene-alloc.c.obj
cc @src/graphene-1.0@sha/graphene-alloc.c.obj.rsp
../src/graphene-alloc.c: In function 'graphene_aligned_alloc':
../src/graphene-alloc.c:94:11: error: implicit declaration of function 'posix_memalign' [-Werror=implicit-function-declaration]
   errno = posix_memalign (&res, alignment, real_size);
           ^~~~~~~~~~~~~~
cc1.exe: some warnings being treated as errors
[2/67] Compiling c object src/graphene-1.0@sha/graphene-euler.c.obj
[3/67] Compiling c object src/graphene-1.0@sha/graphene-box.c.obj
../src/graphene-box.c:53:0: warning: "_WIN32_WINNT" redefined
 #define _WIN32_WINNT 0x0600

In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/crtdefs.h:10:0,
                 from C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:9,
                 from ../src/graphene-private.h:30,
                 from ../src/graphene-box.c:33:
C:/msys64/mingw64/x86_64-w64-mingw32/include/_mingw.h:225:0: note: this is the location of the previous definition
 #define _WIN32_WINNT 0x502

../src/graphene-box.c:688:15: warning: no previous prototype for 'InitBoxFunc' [-Wmissing-prototypes]
 BOOL CALLBACK InitBoxFunc (PINIT_ONCE InitOnce,
               ^~~~~~~~~~~
ninja: build stopped: subcommand failed.

Expected behavior

Ninja completes the build so I can make you a nice mingw-w64-graphene-git package to allow the new GTK3 dependencies to be built on Windows.

Steps to reproduce

These also form updated build instructions for MSYS2.

From an MSYS2 environment:

1. Build mingw-w64-meson with makepkg-mingw -sf (packages are not yet available in the repository because @Alexpux has been busy) Now just install them: pacman -S mingw-w64-i686-meson mingw-w64-x86_64-meson

2. Install the resultant packages: pacman -U *.pkg.tar.xz

3. Install ninja from the repository: pacman -S mingw-w64-{x86_64,i686}-ninja Now pulled in as a dependency.

4. Install graphene's documented dependencies:

   pacman -Syyuu    # repeat as needed, closing the terminal when it tells you
   
   pacman -S automake autoconf libtool pkg-config gtk-doc
   pacman -S glib2   # why not native (mingw-w64-{x86_64,i686}) ?
   

5. From a MINGW64 or a MINGW32 shell,

   cd /usr/src/
   git clone git://github.com/ebassi/graphene
   cd graphene/
   mkdir _build && cd _build
   meson.py ..     # note the different name on these platforms
   ninja
   

At which point it fails with the error above.

Operating system in use

Windows 7 Professional N (on Virtualbox on Debian)

SIMD implementation in use

Not a clue, I only care about getting graphene built sensibly so I can fix wacom stylus tilt in GTK master.

[achadwick]

Apologies for being a bit gruff trapped in a chain of building the tool to make the tool to do a thing right now. Putting together a non-git graphene 1.4.0 in MINGW-packages as penance.

I note that this may be a regression since 1.4.0: the test was working with autofu.

[...]
checking if building for some Win32 platform... yes
checking for aligned_alloc... no
checking for posix_memalign... no
checking for memalign... no
[...]

[ebassi]

We do the same checks in Meson that we did with Autotools, and we conditionally build things depending on the results; that part hasn't changed, and I can quickly verify that the build still works the same way on Linux.

You should have a meson-log.txt under the _build directory, which should tell you whether Meson is able to find various conditional features, like posix_memalign() and InitOnce.

[achadwick]

Still broken as of 80d553a, although at least meson is now available through MSYS2.

build-output.txt
meson-log.txt

[ebassi]

Somebody with a Windows machine and MSYS2 will have to debug this, since I don't have a Windows machine with development tools on it.

[achadwick]

Would patches for a Tea-CI or Appveyor CI build be welcome?

[ebassi]

Yes, as long as they come with the implicit guarantee that somebody will look at Tea-CI/Appveyor, since I don't really have experience with those services.

[achadwick]

They'd operate as automated github checks, so you wouldn't have to check them each time. I don't have the time to devote to their ongoing maintenance; I have enough on my plate already. Really I'm only doing this to try and ensure that the next MyPaint release's GTK will be OK.

Let's get the build working first. This is my first tussle with meson, and I don't know it at all, but it's clearly drawing the wrong conclusion about the presence of posix_memalign(). This is meson 0.35, I will try a newer version.

$ pacman -Ss meson
mingw32/mingw-w64-i686-meson 0.35.1-1 [installed]
    High-productivity build system (mingw-w64)
mingw64/mingw-w64-x86_64-meson 0.35.1-1 [installed]
    High-productivity build system (mingw-w64)

[achadwick]

Meson 0.36.0 does not fix this issue, sadly.

[nirbheek]

This actually works fine for me with MSYS/MinGW (not MSYS2):

Checking for function "aligned_alloc": NO
Checking for function "memalign": NO
Checking for function "posix_memalign": NO

I will also note that the aligned malloc logic is broken: #83 so it's probably best to not build the benchmark at all on MinGW.

[nirbheek]

Till this is figured out, I'd recommend wrapping the posix_memalign check in a if host_machine.system() != 'windows'. With that this bug can be closed and we can track it in Meson. I'll eventually get to it.