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

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