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

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.


Martchus commented on 2016-03-16 20:14

I can not change the headers as you proposed because this would likely break dynamic linkage. Since there is currently no other solution I don't update the package for now.

However, you could try to ask the ANGLE devs. They already gave me the hint how to build the static libs at all but noted that this is not officially supported.

When you tried to add the define before building the static ANGLE libs, did you ensure that all relevant object files from the previous shared build are deleted? It might haven been the case that these just haven't been rebuilt. That's currently my last idea.

Gusar commented on 2016-03-16 17:44

> However, I'm wondering how you managed to build statically without getting all those errors I got.

Simple - I don't build with the kitchen sink included. In serious words, I do a minimal build with just libdvdcss, libdvdread, libdvdnav, zlib, freetype2, libass, luajit, ffmpeg (absolutely no external libs here, just ffmpeg's internals - libavcodec and company). All of them compiled manually, mainly because I compiled them before I knew there's a whole bunch of mingw packages in AUR.

I think I know where your errors come from - just like I had to change lib='EGL' to a whole list of libraries for static angle, you'll have to do similar for all the projects that fail linking for you. The way I see it, when you link statically, you need to tell the linker where to get all the objects that a dynamic library will resolve by itself at runtime.

Martchus commented on 2016-03-16 17:12

Enabling static linking with --enable-static-build flag works. However, I'm getting a lot of errors:

I also needed to adjust some libraries because not all were available as static library. See my comment on mingw-w64-ffmpeg:

You are right, some libs are still linked dynamically (EGL is among them). I think mpv devs to this for the simple reason that static builds are not officially supported by ANGLE. However, I'm wondering how you managed to build statically without getting all those errors I got.

All comments