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

Git Clone URL: https://aur.archlinux.org/mingw-w64-angleproject.git (read-only)
Package Base: mingw-w64-angleproject
Description: ANGLE project (mingw-w64)
Upstream URL: https://chromium.googlesource.com/angle/angle/+/master/README.md
Licenses: BSD
Submitter: brcha
Maintainer: Martchus
Last Packager: Martchus
Votes: 12
Popularity: 0.009064
First Submitted: 2013-04-23 18:00
Last Updated: 2016-04-17 22:40

Dependencies (5)

Required by (4)

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

Pinned Comments

Martchus commented on 2016-05-18 21:57

All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs
There also exist a binary repository: https://martchus.no-ip.biz/repo/arch/ownstuff

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.

Latest Comments

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: https://git.archlinux.org/svntogit/packages.git/tree/trunk/makepkg.conf?h=packages/pacman
where architecture specific flags are replaced within the PKGBUILD: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/pacman

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): https://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros_and_variables
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: https://sourceforge.net/p/mingw-w64/bugs/548/.) 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

Hi,

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 https://wiki.archlinux.org/index.php/MinGW_package_guidelines#Packaging.

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
target="win32"
CXXFLAGS+=" -march=i686"
else
target="win64"
CXXFLAGS+=" -march=x86-64"
fi

Martchus commented on 2016-05-18 21:57

All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs
There also exist a binary repository: https://martchus.no-ip.biz/repo/arch/ownstuff

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.

[1] https://bugs.chromium.org/p/angleproject/issues/detail?id=1251

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: https://gist.github.com/Martchus/bd6cc7ba8df26f9eac7b

I also needed to adjust some libraries because not all were available as static library. See my comment on mingw-w64-ffmpeg: https://aur.archlinux.org/packages/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 https://martchus.no-ip.biz/repo/arch/ownstuff/os/x86_64/?

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

[1] http://pastebin.ca/3401081
[2] https://groups.google.com/forum/#!topic/angleproject/xKmUgKZFpgY

Martchus commented on 2016-03-14 18:03

Since the usage of __declspec/__attribute__ is controlled according particular macro definitions, it shouldn't be hard to pick the right one by just defining/undefining relevant definitions before including the header. This way no further manipulation of the files is required.

I'm doing the same thing in entry_points_shader.cpp (https://aur.archlinux.org/cgit/aur.git/tree/entry_points_shader.cpp?h=mingw-w64-angleproject) which I included to export shader symbols in libGLESv2.dll.

Gusar commented on 2016-03-14 14:52

Thanks for fixing the static libs. Though I forgot a little hack is needed to get them usable, a proper fix will need to be done by upstream. In the current code, all the __declspec stuff needs to be removed from the header files, otherwise static linking fails. Some sed is useful here:

sed -i 's/ __declspec.*$//' include/platform/Platform.h include/KHR/khrplatform.h include/export.h include/GLSLANG/ShaderLang.h

I'm quite sure this will break dynamic linking, so it's not something you can put into the PKGBUILD. But as it's headers, I can do it locally after installing the mingw-w64-angleproject binary package.

Martchus commented on 2016-03-13 18:31

Since I usually don't link statically I didn't test them and I didn't really know what these thin archives are. Thanks for making this clear and providing the patch.

"Angle is a real pain to build,"
In fact the current problems are:
- mingw-w64 lacks some required header files.
- The gyp Makefile generator seems broken. At least concurrent builds don't work for me.
- I'm unable to enable the ninja generator, so this workaround is not possible, too.
- Generation of import libs and use of *.def files must be patched.
- 32-bit *.def files are not provided by ANGLE.
- Shader symbols must be exported manually by patching the project file to be able to build Qt WebKit which must be patched as well because ANGLE devs decided to change the API.
- Building static libs is not officially supported but seems to work anyways (thanks again for your patch).

Gusar commented on 2016-03-13 15:20

A note on static libraries: "Thin archives" merely reference object files, they don't contain any objects themselves. Which means one needs the original object files around, something this package doesn't provide. So it's not possible to use this package to statically build Angle into a binary, the thin archives by themselves are useless. I suggest turning them into actual static libraries. Googling around, I found some code to do that, modified for this PKGBUILD it looks like this (add it after the static libs are built):

for lib in out/Debug/src/lib*.a; do
${_arch}-ar -t $lib | xargs ${_arch}-ar rvs $lib.new && mv $lib.new $lib;
${_arch}-ranlib $lib
done

What the code does: "ar -t" lists the object files referenced by the thin archive, these object files are then packed into a new library, which then replaces the thin archive. Finally, ranlib is needed to add an index to the new library. With these new libs I was able to cross-compile mpv.exe with Angle statically built in.

Thanks for this package BTW. Angle is a real pain to build, I don't think I'd get anywhere if it weren't for your work.

Martchus commented on 2016-03-10 19:30

Just rebuild this, if you want this to work with Qt WebKit.

I included a patch to export symbols which are required to use the C++ interface declared in ShaderLang.h via libGLESv2.dll. This interface is used in Qt WebKit.

I hope I didn't break anything further in the build system because I had to change a few details. The units providing the interface are now build as part of the libGLESv2 target which now no longer depends on an extra static library providing the interface.

Martchus commented on 2016-02-27 21:04

I'll add the -f flag. I wanted to update the package for other small changes anyways. However, I can't reproduce the issue - rm doesn't ask me when building this package.

I know what the guideline says. When adding -git suffix I would remove the commit ID of course. But you're right, for this package it is better to stick with a particular commit for a while.

Thanks for providing me some sources but I've already checked them. These repositories are helpful but not completely appropriate:
Qt 5/Fedora: They include a lot of patches. Including a lot of patches is not the Arch way. Especially since my Qt 5 applications (including Qt WebKit) seem run fine without them. Additionally Fedora sticks with a commit ID from 2014 which is quite old and a lot of patches don't apply anymore.
MSYS2: The current version of the package doesn't work. I already submitted a pull request (https://github.com/Alexpux/MINGW-packages/pull/1108).

ant32 commented on 2016-02-27 20:20

Could you change ge line to include 'f' so it doesn't ask the user for input during building?
rm -fr .git

As far as adding -git to the package don't
https://wiki.archlinux.org/index.php/VCS_package_guidelines
says
Suffix pkgname with -cvs, -svn, -hg, -darcs, -bzr, -git etc. unless the package fetches a specific release.
Building the package always seems to require patches and hacks so it's good to have a package that won't break because of a git update. Hopefuly I'm wrong on the last statemnt.

Keeping it updated according to the following may be easiest.
http://code.qt.io/cgit/qt/qtbase.git/log/src/3rdparty/angle
http://pkgs.fedoraproject.org/cgit/rpms/mingw-angleproject.git/
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-angleproject-git

Martchus commented on 2016-02-21 22:40

I adopted the package to fix the gyp dependency.

Since the current version is based on a snapshot from 2014 I also decided to update the package. However, I had to do a few adjustments to make it compile:
- I removed most of the patches since these can't be applied anymore. But it seems like all these patches aren't required anymore.
- I had to provide some header files which seem to be missing in mingw-w64-headers. I outsourced these headers to another repository because the max. upload size would be exceeded otherwise.
- I disable concurrent builds because building concurrently is broken.
- In the current version the static libs are created manually. As the selection of object files is no longer valid for the new version I decided to use "-D angle_gl_library_type=static_library" build flag to create the static libs with the build system.

I hope the package still works. At least my Qt 5 apps work with the new version without needing to recompile any Qt 5 packages.

As there are no official releases of the ANGLE project we might consider making this a *-git package? On the other side, compiling this might require some more adjustments in the future so sticking with a particular commit for a while isn't a bad idea either.

FreddieChopin commented on 2015-10-08 15:39

Just change the dependency in the PKGBUILD file from "gyp-svn" to "gyp-git" and it works.

kuldeepdhaka commented on 2015-06-28 13:01

http://sourceforge.net/projects/mingw-w64-archlinux/files/x86_64/ contain gyp-svn, hope this helps.

jeho commented on 2015-05-13 14:38

Looks like gyp-svn is no longer present but still in the dependencies.

ant32 commented on 2015-01-16 05:56

https://bugs.archlinux.org/task/43468

xantares commented on 2014-06-04 13:53

commit has been backported in mingw-w64-headers!
xan.

stas commented on 2014-05-05 21:28

Found mingw-w64 upstream patch to fix intrinsics conflict compilation problem with GCC 4.9.0.
Here is relevant commit: http://sourceforge.net/p/mingw-w64/code/6602/ .

stas commented on 2014-05-05 20:28

Cannot build this with mingw-w64 GCC 4.9.0 because of some declaration conflict between intrin.h from mingw-w64 and x86intrin.h from GCC 4.9.0.

I checked that the latest version of angleproject has some modifications which could fix this conflict but I am struggling to build latest version too.

I do not feel comfortable making any modifications in the source code because I have little knowledge in this project.

Has anybody succeeded building it with the latest MinGW-W64 GCC 4.9?
Any help will be appreciated. Thanks

ant32 commented on 2014-02-07 17:07

1. Fix source path
2. auto load d3dcompiler library
Repo and Binaries http://mingw-w64-archlinux.sourceforge.net/
Changes https://github.com/ant32/pkgbuild/commits/master/mingw-w64-angleproject

ant32 commented on 2014-01-26 03:01

1. Clone pacific commit via source instead of in prepare
2. Changed pkgbuild to my style. Will try maintaining it. If you'd like to maintain it please email me.
Repo and Binaries http://mingw-w64-archlinux.sourceforge.net/
Changes https://github.com/ant32/pkgbuild/commits/master/mingw-w64-angleproject

ant32 commented on 2014-01-22 03:51

added git to makedepends and fixed the permissions of the files in the src tarball

ant32 commented on 2014-01-22 03:43

It's a bit anoying when perissions of packages don't allow group or others to view the files. This cause building in a clean chroot to fail. I'm not blaming anyone since a lot of packages are this way.
# ls -l mingw-w64-angleproject
total 36
-rw-r--r-- 1 root root 1751 Oct 29 01:46 angleproject-export-shader-symbols.patch
-rw------- 1 root root 620 Oct 29 01:46 angleproject-fix-case-sensitive-include.patch
-rw------- 1 root root 10031 Apr 20 2013 angleproject-fix-mingw-compatibility.patch
-rw------- 1 root root 3291 Apr 20 2013 angleproject-fix-typedefs-for-win64.patch
-rw------- 1 root root 1232 Apr 20 2013 angleproject-include-import-library-and-use-def-file.patch
-rw------- 1 root root 5844 Jan 20 10:45 PKGBUILD

jellysheep commented on 2014-01-20 16:48

You are right. It was meant to ease PKGBUILD updating, but in fact it is not worth. I removed the pkgver() function again.

ant32 commented on 2014-01-20 00:00

I like it that you removed the source from the tar ball. But the pkgver function looks useless if you clone a specific revision.

jellysheep commented on 2014-01-19 21:44

Updated the PKGBUILD to fetch sources from git upstream repo and added a pkgver() function:
https://github.com/jellysheep/pkgbuilds/commit/e17154c3c5deb612ec56aca350eab1edf7e4f797
Please write a comment if something does not work/build as expected.

@xantares: I don't know if you disowned the package so I can update it (as ant32 supposed), however you can take it over again if you want.

jellysheep commented on 2014-01-19 21:41

Updated the PKGBUILD to fetch sources from git upstream repo and added a pkgver() function.
Please write a comment if something does not work/build as expected.

@xantares: I don't know if you disowned the package so I can update it (as ant32 supposed), however you can take it over again if you want.

jellysheep commented on 2014-01-07 21:54

Just wanted to inform you that upstream sources moved to a git repository: git+https://chromium.googlesource.com/angle/angle
However as Fedora is at r2215 of angleproject as well, your package is still up-to-date.

For the git version of this package I added automatic version number generation:
pkgver() {
cd "$srcdir/angleproject"
head -n 4 src/common/version.h | sed -e 's/BUILD_REVISION /BUILD_REVISION r/' -e 's/.* //' | tr '\n' '.' | sed 's/.$/\n/'
}
You can adopt it if you want.

xantares commented on 2013-11-13 12:30

updated

Schala commented on 2013-11-12 23:15

Also needs staticlibs option

ant32 commented on 2013-11-11 14:08

Please consider updating this to a newer release. jellysheep sent me a updated src tarball a while ago. I did not test it. r2215 is what fedora is currently using. https://www.dropbox.com/s/xa9a68rgjzokzw4/mingw-w64-angleproject-1.0.0.r2215-1.src.tar.gz

ant32 commented on 2013-09-19 23:03

this now builds against headers-svn and crt-svn

ant32 commented on 2013-08-20 16:47

Could you please add mingw-w64-headers-secure mingw-w64-crt-secure as makedepends?

ant32 commented on 2013-06-20 15:12

wouldn't it work to add mingw-w64-{crt,headers}-secure as a build dependency? I'm asking this because I think that would help yaourt?

brcha commented on 2013-04-23 18:03

For now you have to use this with mingw-w64-{crt,headers}-secure because the current mingw-w64-{crt,headers}-svn don't include the secure headers.