Package Details: mingw-w64-angleproject 2.1.r6381.9f09037-2

Git Clone URL: (read-only)
Package Base: mingw-w64-angleproject
Description: ANGLE project (mingw-w64)
Upstream URL:
Licenses: BSD
Conflicts: mingw-w64-angleproject
Provides: mingw-w64-angleproject
Submitter: brcha
Maintainer: Martchus
Last Packager: Martchus
Votes: 12
Popularity: 0.000001
First Submitted: 2013-04-23 18:00
Last Updated: 2016-12-04 17:05

Pinned Comments

Martchus commented on 2016-05-18 21:57

All my packages are managed at GitHub where you can also contribute directly:
There also exist a binary repository:

Latest Comments

Schala commented on 2017-08-09 22:07

gyp is now in official repo

Martchus commented on 2017-08-08 15:48

@jbg I obviously didn't have that issue last time I built this package (December last year). Maybe a change in the behaviour of depot-tools/ninja.

General note: I'll update mingw-w64-angleproject again when updating mingw-w64-qt5-webkit to 'ng' version. Then I'll drop the patches to make WebKit use this package which will allow to get rid of `0005-Export-shader-API-via-libGLESv2.dll.patch`. The idea of using system ANGLE rather than the bundled version for WebKit from the previous maintainer was nice, but it has become too hard to maintain.

jbg commented on 2017-08-08 08:51

To make this package build, I had to change `--depth .` to `--depth ..` in gyp_args and `out/Release` to `../out/Release` in ninja_args, in the build function in PKGBUILD.

Martchus commented on 2016-11-06 19:23

I've just pushed a new commit. Added the flags for optimization and updated the to the latest version. However, I haven't tested whether it actually runs.

This is using now dept-tools and ninja (seems to be the recommend way of building ANGLE). Concurrent builds are now not broken anymore, so this should build much faster. I hope I haven't broken shader API required by Qt WebKit.

Martchus commented on 2016-08-11 18:35

As I already said, the flags are taken from Fedora. The Fedora devs chose the flags so they match as best as possible the default flags for regular packages under Fedora (according to some guy at #fedora-mingw IRC channel). I agree with that strategy. Hence, here we should use flags which match best the default flags under Arch.

The default flags under Arch are defined makepkg.conf:
where architecture specific flags are replaced within the PKGBUILD:

So the default flags under Arch indeed include the proposed flag. I think that would be a good reason to also include the flags here.

However, for consistency that decision should be done for all mingw-w64 packages and not only for this one. Till a general decision is made I will not update the flags. And there are more things to consider.

I'm not sure about the default flags in Fedora but the Fedora Wiki states march/mtune as optional flags (whatever this means):
That means that Fedora devs differ here from their own default flags and maybe they have a good reason for that.

I should also mention that the current version of mingw-w64 has some serious bugs. The i686 version of binutils is more or less unusable (just have a look at the bug reports concerning the mingw-w64-binutils package).
There are also bugs triggered by optimization. For example if you instantiate std::stringstream inside a library built with at least -O1 the application crashes with a page fault. (I already filed a bug report bug haven't got any response so far: I've just took a look and noticed that ANLGE also makes use of that class so if you experience crashes that might be the reason. (That means using the flags currently present in the PKGBUILD is actually a bad idea with the current version of mingw-w64!)

So you see that adding flags (especially concerning optimizations) might has side affect such as very annoying bugs. Hence I suppose it is best to wait for a more stable release of mingw-w64 before changing the flags for mingw-w64 packages. Some testing would also be required.

BTW: I recently tried to rebuild this using a newer commit ID and it failed. Not even because of the patches but because of missing headers provided by another Google project. I guess it would be better if this PKGBUILD would use depot_tools and maybe ninja according to the build instructions.

b00rt00s commented on 2016-08-09 21:41

Of course the package builds correctly, but it's not optimized, I think. The flags could be added for the sake of performance. I must, however, admit that I'm not expert here (just guessing).

Martchus commented on 2016-08-09 16:18


of course would it be possible to add the flag. However, what would be the benefit? As far as I see it the package builds correctly without it.

BTW: I've chose the flags according to

b00rt00s commented on 2016-08-09 14:54

I looked at the CXXFLAGS and I cannot see '-march=' statement. Is it possible to modify the PKGBUILD such way:

if [[ ${_arch} == i686-w64-mingw32 ]]; then
CXXFLAGS+=" -march=i686"
CXXFLAGS+=" -march=x86-64"

Martchus commented on 2016-05-18 21:57

All my packages are managed at GitHub where you can also contribute directly:
There also exist a binary repository:

Gusar commented on 2016-03-16 20:49

Yes, everything from previous build attempts is deleted.

About angle devs, there's already an upstream bug report [1], hopefully there will be some movement there, but I kinda have my doubts. As it is, it seems I have no other option but to build myself with modified headers. Maybe I'll play around further in the coming days, we'll see.


All comments