Package Base Details: mingw-w64-angleproject

Git Clone URL: https://aur.archlinux.org/mingw-w64-angleproject.git (read-only)
Submitter: brcha
Maintainer: Martchus
Last Packager: Martchus
Votes: 12
Popularity: 0.000000
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: 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 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.