Package Details: mingw-w64-angleproject-samples 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 samples (mingw-w64)
Upstream URL: https://chromium.googlesource.com/angle/angle/+/master/README.md
Licenses: BSD
Conflicts: mingw-w64-angleproject-samples
Provides: mingw-w64-angleproject-samples
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 »

b00rt00s commented on 2016-08-09 21:41 (UTC)

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

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

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

Gusar commented on 2016-03-16 20:49 (UTC)

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

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

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

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

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.

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