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

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

Pinned Comments

Martchus commented on 2016-05-18 21:57 (UTC)

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

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

Martchus commented on 2016-03-15 21:22 (UTC) (edited on 2016-03-15 21:24 (UTC) by Martchus)

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 (UTC) (edited on 2016-03-15 17:10 (UTC) by Gusar)

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 (UTC) (edited on 2016-03-15 14:08 (UTC) by Martchus)

"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 (UTC)

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 (UTC)

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 (UTC) (edited on 2016-03-14 14:53 (UTC) by Gusar)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2016-03-11 19:32 (UTC) by Martchus)

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 (UTC) (edited on 2016-02-27 21:10 (UTC) by Martchus)

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

« First ‹ Previous 1 2 3 4 5 6 Next › Last »