Package Details: mingw-w64-angleproject 2.1.r5707.5858f7e-1

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

Dependencies (5)

Sources (7)

  • additional-mingw-header
  • angleproject-include-import-library-and-use-def-file.patch
  • angleproject
  • entry_points_shader.cpp
  • libEGL_mingw32.def
  • libGLESv2_mingw32.def
  • provide_mbstowcs_s_for_xp.patch

Latest Comments

Martchus commented on 2016-03-31 12:18

When updating to Qt 5.6.0 I've noticed that the latest ANGLE is not Windows XP compatible. At least under my test VM I've got an error that the function mbstowcs_s is not available. Because Qt still provides XP support and this package is actually meant to be used for Qt I decided to provide a patch for backward compatibility. It just provides an own implementation of the mentioned function. I hope it is correct and I didn't break anything else.

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.

Gusar commented on 2016-03-16 14:37

I use sort of a hack to build statically - I remove the import libs (.dll.a). There's the --enable-static-build switch, but it doesn't work for everything. Then, you need to specify all libraries that will get linked in - in mpv's wscript, find the egl-angle section and change lib='EGL' to lib=['EGL', 'GLESv2', 'ANGLE', 'angle_common', 'translator', 'translator_lib', 'preprocessor', 'dxguid', 'd3d9', 'gdi32', 'stdc++']

As for verbosity, there's build/config.log, it contains basically everything you'd want to know.

Martchus commented on 2016-03-15 21:22

Ok, so adding those definitions doesn't resolve the problem.

I just tried to build mpv myself to reproduce the issue and it compiled - however it "just" linked dynamically by default. Then tried to link statically to be able to reproduce the error, but I'm unable to convince waf to link statically. How is that achieved? Which commands do you use to build mpv? Is there a way to make waf more verbose? Currently I can't see which linker flags are actually used.

When using my repository, be aware that is might not be always available since it is just home hosted.

Gusar commented on 2016-03-15 15:00

Yes, I'm referring to your binary repository (my goal is to be able to use that, instead of needing to compile angle myself). The success I had was when I built my own package with that sed line added to the PKGBUILD. Your package, built without that, doesn't work. I should've mentioned that, sorry for the confusion.

Settings those defines just for mpv doesn't work (same error). So they'll need to be set also when building the static libs. Using CFLAGS/CXXFLAGS doesn't get them picked up by gyp, while it does work with waf. Not that I liked it before, but I'm beginning to actively dislike gyp. I'll do a search about gyp to see if it's possible to add preprocessor defines from the command-line. Note that I had to set the flags like so: CFLAGS="-DGL_APICALL= -DEGLAPI=" (the '=' is important)

EDIT: I added -DGL_APICALL= -DEGLAPI= to where the PKGBUILD already sets CXXFLAGS. Looking carefully at the make output, they're there. But the resulting libEGL.a still contains for example _imp___ZN3egl14GetProcAddress instead of ZN3egl14GetProcAddress

Martchus commented on 2016-03-15 13:58

"I couldn't successfully statically link using your binary package."
Are you referring to my binary repository at

"With these new libs I was able to cross-compile mpv.exe with Angle statically built in."
So the package works in general (with the modifications you mentioned) but the binary package in my repository doesn't? Or have you just found out that it doesn't work after all?

"So I guess the next step is convincing gyp to add the defines when building the static libs, and then convincing waf (mpv's build system) to add them."
I think adding additional definitions can be achieved by simply setting CFLAGS+='-DGL_APICALL -DEGLAPI' CXXFLAGS+='-DGL_APICALL -DEGLAPI'. This way I also added additional include directories. This approach should work for all (meta) build systems which actually just generate a Makefile (cmake, qmake, gyp, ...). I don't know whether it works for waf.

These definitions will prevent that the compiler assumes stdcall decorated symbols are present. Your linker errors indicate that the linker is looking for stdcall decorated symbols but the library only contains regular symbols. If this conjecture is true, you should be able to link if you add the definitions as described when building mpv but without the need to modify/rebuild this package. Additionally, if this conjecture is true this problem should only occur when building for i686 but not when building for x86_64.
Unfortunately my experience with static linking and the name mangling behaviour under MS Windows is limited so that's only my best guess.

Gusar commented on 2016-03-14 21:36

I couldn't successfully statically link using your binary package, I get [1]. According to [2], one needs to mangle the headers or do -DGL_APICALL -DEGLAPI both when compiling the static Angle libs and when compiling the application (mpv in my case).

So I guess the next step is convincing gyp to add the defines when building the static libs, and then convincing waf (mpv's build system) to add them. Tomorrow though, it's bed time for me now.


All comments