Package Details: proton-ge-custom 2:GE.Proton7.24-1

Git Clone URL: https://aur.archlinux.org/proton-ge-custom.git (read-only, click to copy)
Package Base: proton-ge-custom
Description: Compatibility tool for Steam Play based on Wine and additional components, GloriousEggroll's custom build
Upstream URL: https://github.com/GloriousEggroll/proton-ge-custom
Keywords: dxvk proton steam valve vkd3d wine
Licenses: custom
Provides: proton
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 22
Popularity: 2.39
First Submitted: 2020-03-23 23:52 (UTC)
Last Updated: 2022-06-30 14:45 (UTC)

Required by (1)

Sources (30)

Pinned Comments

loathingkernel commented on 2020-11-21 10:28 (UTC) (edited on 2022-06-15 14:13 (UTC) by loathingkernel)

Notes about this package

  • If you encounter issues while using this package, please contact me here first before reporting an issue to the upstream repository. Don't post logs, link to them. If you are using Manjaro, another derivative or an AUR helper, please mention it, I DO NOT TEST AGAINST THEM AND I CANNOT KNOW WHAT MIGHT BE WRONG WITH THE DISTRO/HELPER OF YOUR CHOICE.

  • It takes a LOT of time and space to build. Building with multiple jobs helps but might cause builds to fail in rare cases. Be sure to have at least 16GB of RAM if you are building on tmpfs

  • It is NOT built against Steam Linux Runtime (Sniper, Soldier, etc) and as such it doesn't require it. Still, is detected by Steam and works properly (preferable through steam-native).

  • This PKGBUILD uses CFLAGS, CXXFLAGS and LDFLAGS hardcoded in the PKGBUILD itself. By default it uses the same C[XX]FLAGS as upstream, namely -march=nocona and -mtune=core-avx2. To change them you will have to edit the PKGBUILD itself. Due to the nature of this package some flags can cause it to fail to build or not function properly. I try to filter them out but it is based on testing. If you have a feeling that compile-time options are involved in the issues you are having please include them in your comment. Currently the filtered options are -fstack-protector-{,-strong,-all}(dxvk and vkd3d only), -fno-plt, -z,relro, -z,now. Also the use of AVX instructions is disabled through -mno-avx.

  • If you are not using CFLAGS and CXXFLAGS specific to your system this package won't offer much in terms of performance as the upstream build flags already target the nocona (Core2) architecture. It will possibly perform worse than upstream. The only benefits you get is not depending on steam linux runtime as well as linking to Arch libraries. If you still want to build it, you can uncomment the relevant lines in the PKGBUILD to enable CFLAGS and CXXFLAGS similar to the upstream.

  • There have been reports with afdko failing to find its dependencies during building. I can't do anything about that as I don't maintain that package. It is NOT an issue with this package and I haven't found a way to not depend on it. Please don't report fails due to afdko (or any of its python- dependencies, they are pulled in due to afdko and only used by that), it has been discussed enough. There are possible workarounds in the comments.

  • It contains a patch to store game prefixes in the main Steam Library under $HOME/.local/share/Steam/steamapps/compatdata. It helps with isolation of game prefixes between users and works around issues with shared libraries on NTFS partitions due to drive symlinks. To enable it, set the PROTON_USER_COMPAT_DATA env variable to 1.

  • This package requires a Rust 32 bit target, please run rustup target install i686-unknown-linux-gnu BEFORE posting any issues if you're using rustup.

Latest Comments

medzik commented on 2022-06-06 19:18 (UTC)

after delete 0002-RevertMe-Use-one-job-for-autoconf-targets-because-of.patch does not compile in clean chroot

loathingkernel commented on 2022-05-31 20:26 (UTC) (edited on 2022-05-31 20:51 (UTC) by loathingkernel)

@RubenKelevra Yes, I do have issues with it, and I do not really need to elaborate further, since there is a comment history that can tell you why it is a bad idea, but here is the gist.

You set one specific platform in your PKGBUILD and I replaced it with a dynamic one.

And there is a very good reason for that. native in the case of this package doesn't mean "better" nor "more performant". There have been reports where targeting more recent instruction sets had negative effects. Forcing native to anyone who doesn't know better but just found your package is not a good thing. It is even malicious given the time it takes to build.

The point of the package is just, that I want to build packages with native on my machines

This is the very definition of your personal PKGBUILD, it fits you, it doesn't fit anyone else for reasons I described above.

and I share the package on the AUR since there may be other people wanting to do the same.

If they want to do the same they can use edit the PKGBUILD themselves. It is almost like signing a waiver, when you edit it you have read the comments in the PKGBUILD and you have accepted the risks. In case you provide it readily made, it means you have to support it, and I don't want to support building with native, people who understand the risks can do that without any hand-holding.

Still having problems with that? If so - can you elaborate? :)

Yes I still do, and especially with the condescending smiley face.

My question was just geared towards the fact that paru seems to "think" that the gits do change the code used in this repository on each and every commit.

According to the creator of paru, because they are not pinned, but I firmly believe that they are wrong in that regard and I have commented on why here

lem0nify commented on 2022-05-31 20:07 (UTC)

Oh, finally. Seems I had to choose stable toolchain as default AND install i686 target. Now it builds.

RubenKelevra commented on 2022-05-31 20:04 (UTC)

The AUR is not a personal repository, and this looks like a change that would be useful only to you. This should be handled in some other private to you way and not in the AUR.

Not sure what on a natively building package is "personal". You set one specific platform in your PKGBUILD and I replaced it with a dynamic one. As long as you build it on the same machine it will be still reproduceable.

My question was just geared towards the fact that paru seems to "think" that the gits do change the code used in this repository on each and every commit.

The point of the package is just, that I want to build packages with native on my machines and I share the package on the AUR since there may be other people wanting to do the same. If not – this doesn't hurt.

Still having problems with that? If so - can you elaborate? :)


While I agree that march=native is not suitable for AUR without description on which architecture it was build on, in general such a march=CPU architecture package has some value for people on newer architectures.

The march=native is part of the description of the package, so moving the build package from one computer to the next doesn't make much sense in this case. :)

loathingkernel commented on 2022-05-31 19:43 (UTC)

@lem0nify rustup target install i686-unknown-linux-gnu

lem0nify commented on 2022-05-31 19:14 (UTC)

Still no idea how to build it with rust installed by rustup without installing lib32-rust-libs ?

loathingkernel commented on 2022-05-29 19:51 (UTC)

People are free to try any optimizations they want, that is why I packaged this software in this way. One case could be made for x86_64_v3 but even then, editing the pkgbuild is simple, there is no need for iffy automation through package names. It's Arch ffs.

@ms178 AVX and AVX2 from my testing do not offer any performance benefit, at all, they even have had the opposite effect in some cases. Also many 32bit games are broken with these flags enabled.

ms178 commented on 2022-05-29 18:36 (UTC) (edited on 2022-05-29 18:38 (UTC) by ms178)

@loathingkernel, RubenKelevra

While I agree that march=native is not suitable for AUR without description on which architecture it was build on, in general such a march=CPU architecture package has some value for people on newer architectures. The benefits of such a CPU-architecture specific package would be even greater if the current limits on AVX and AVX2 in the PKGBUILD and patches were lifted. From my own testing today with the dxvk and vkd3d-proton MinGW packages, I found that these ISA restrictions are no longer needed there (yes, I checked and edited all entries in the patches and PKGBUILDs accordingly and checked the terminal output). I don't know if these restrictions are still needed for the proton-ge-custom package as I am still waiting for a fixed mingw-binutils to test that, but I would encourage people to try it themselves on the above mentioned packages and see if they see some performance gains (for anyone interested, see my customized dxvk-mingw and vkd3d-proton-mingw-git PKGBUILDS and patches at https://github.com/ms178/archpkgbuilds/tree/main/packages/).

loathingkernel commented on 2022-05-29 13:02 (UTC) (edited on 2022-05-29 16:25 (UTC) by loathingkernel)

@RubenKelevra Actually no, I am not ok with that. The reasons are purely technical. You can take a look to the comments of this and proton packages for various failures due to CFLAGS. I would prefer if people want to change it, they have looked through the PKGBUILD first. Also using native goes against the spirit of reproducibility in your previous comment as each package is going to be different depending on the machine it is going to be built on.

avoid having to modify the PKGBUILD on each and every machine and update.

The AUR is not a personal repository, and this looks like a change that would be useful only to you. This should be handled in some other private to you way and not in the AUR.

RubenKelevra commented on 2022-05-29 12:40 (UTC)

Thanks for the fast response @loathingkernel!

This makes sense and I'll look into the issue on the paru side. :)

Btw I created a tiny fork of this package with the -native suffix to avoid having to modify the PKGBUILD on each and every machine and update. Hope you're alright with that. :)

loathingkernel commented on 2022-05-28 18:31 (UTC) (edited on 2022-05-28 18:46 (UTC) by loathingkernel)

@RubenKelevra That is a paru or a configuration issue. The correct commits are defined in the way of git submodules and the PKGBUILD respects those. The PKGBUILD itself is absolutely predictable and reproducible unless upstream decided to force-push and overwrite a specific commit, which in either way it was handled, it would be problematic. The exact version depends on the containing repo's tag and it doesn't change for each specific version.

I don't know why paru wants to update a package when the PKGBUILD's version didn't change and it doesn't have a vcs suffix as if it was a vcs package, but that is not something the PKGBUILD should fix.

RubenKelevra commented on 2022-05-28 17:04 (UTC)

Paru seems to like to rebuild this package on every single commit on every single git that's linked.

I was wondering if you could freeze the other gits just to a tag/commit and also make the build more predictable/reproduceable?

Thanks!

patlefort commented on 2022-05-20 00:22 (UTC)

@loathingkernel Builds fine for me with your fix, thank you very much.

ms178 commented on 2022-05-19 23:59 (UTC)

@loathingkernel I spent some hours today but still couldn't get it to build, as I now face problems with dxvk-nvapi. But as I customized the files a bit, eg. changed the jobs to 4 in the RevertMe patch and use other buildflags, that might need more experimentation to what went wrong this time.

loathingkernel commented on 2022-05-19 08:22 (UTC)

@pattlefort @dmfay @ms178 I have made an unversioned update to this package that should fix the issue. The reason it is unversioned is because of an unrelated upstream issue wine takes a long time to build, and I didn't want to force an update to the people who have it working already. The gotcha is that it disables inline-asm for the x86 ffmpeg (while enabling lto and optimizations for ffmpeg similar to the rest of the libraries) so I don't know of the performance impact it might have.

loathingkernel commented on 2022-05-18 14:57 (UTC) (edited on 2022-05-18 22:11 (UTC) by loathingkernel)

@ms178 I am just beyond that point. I tried what the gentoo bugreport suggested but it still failed. I also tried changing optimization levels after but any of the permutations I tried didn't help either.

Edit: I have a fix I think, I will update tomorrow after I test.

ms178 commented on 2022-05-18 13:17 (UTC) (edited on 2022-05-18 13:30 (UTC) by ms178)

@loathingkernel @pattlefort @dmfay

I also hit this error, starting with GCC 12.0.1. - I've traced it down to the following and related errors in the 32-bit ffmpeg build:

/libavcodec/x86/cabac.h:192:5: error: ‘asm’ operand has impossible constraints asm volatile( ^

These errors surprisingly don't stop the build process though and also see the build never finish with the reported process from @dmfay still running. Some Genotoo users did hit this issue in the past: https://bugs.gentoo.org/578802 - they solved it with "--disable-optimizations" in the configure options (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6a2691a2bb66bd0497e458b0a00414507e8e99c0) but I could not test if that actually works in our case. Can someone prepare a patch which I could test?!

loathingkernel commented on 2022-05-18 08:25 (UTC) (edited on 2022-05-18 08:25 (UTC) by loathingkernel)

@dmfay @patlefort thank you for reporting it. I have hit the same issue, I am looking into it but haven't found a solution yet.

dmfay commented on 2022-05-16 20:01 (UTC)

I'm also seeing it hang in the ffmpeg build, 4h30m and counting on a Ryzen 9 5900X. Last few log lines:

i686-pc-linux-gnu-gcc -shared -Wl,-soname,libswscale.so.5 -Wl,-Bsymbolic -Wl,--version-script,libswscale/libswscale.ver -Llibavcodec -Llibavdevice -Llibavfilter -Llibavformat -Llibavresample -Llibavutil -Llibpostproc -Llibswscale -Llibswresample -Wl,-O1,--sort-common,--as-needed  -Wl,--as-needed -Wl,-z,noexecstack -Wl,--warn-common -Wl,-rpath-link=:libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample  -o libswscale/libswscale.so.5 libswscale/alphablend.o libswscale/gamma.o libswscale/hscale.o libswscale/hscale_fast_bilinear.o libswscale/input.o libswscale/log2_tab.o libswscale/options.o libswscale/output.o libswscale/rgb2rgb.o libswscale/slice.o libswscale/swscale.o libswscale/swscale_unscaled.o libswscale/utils.o libswscale/vscale.o libswscale/x86/hscale_fast_bilinear_simd.o libswscale/x86/input.o libswscale/x86/output.o libswscale/x86/rgb2rgb.o libswscale/x86/rgb_2_rgb.o libswscale/x86/scale.o libswscale/x86/swscale.o libswscale/x86/yuv2rgb.o libswscale/x86/yuv_2_rgb.o libswscale/yuv2rgb.o -lavutil -lm -pthread -lva-drm -lva -lva-x11 -lva -lvdpau -lX11 -lm -lva -lXv -lX11 -lXext
/usr/bin/ld: libswscale/x86/hscale_fast_bilinear_simd.o: warning: relocation in read-only section `.text.unlikely'
/usr/bin/ld: warning: creating DT_TEXTREL in a shared object
cd ./libswscale/ && ln -s -f libswscale.so.5 libswscale.so

Stuck process cmdline:

> cat /proc/52048/cmdline
/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/cc1-quiet-I.-Isrc/-imultilib32-MMDlibavcodec/h264_cabac.d-MFlibavcodec/h264_cabac.d-MTlibavcodec/h264_cabac.o-D_REENTRANT-D_ISOC99_SOURCE-D_FILE_OFFSET_BITS=64-D_LARGEFILE_SOURCE-D_POSIX_C_SOURCE=200112-D_XOPEN_SOURCE=600-DPIC-DZLIB_CONST-DHAVE_AV_CONFIG_H-DBUILDING_avcodecsrc/libavcodec/h264_cabac.c-quiet-dumpdirlibavcodec/-dumpbaseh264_cabac.c-dumpbase-ext.c-m32-mfpmath=sse-march=nocona-mtune=core-avx2-mno-avx2-mfpmath=sse-mstackrealign-mno-avx-gdwarf-2-gdwarf-2-gstrict-dwarf-g-O3-O3-O3-Wdeclaration-after-statement-Wall-Wdisabled-optimization-Wpointer-arith-Wredundant-decls-Wwrite-strings-Wtype-limits-Wundef-Wmissing-prototypes-Wno-pointer-to-int-cast-Wstrict-prototypes-Wempty-body-Wno-parentheses-Wno-switch-Wno-format-zero-length-Wno-pointer-sign-Wunused-const-variable=0-Wno-bool-operation-Wno-char-subscripts-Werror=format-security-Werror=implicit-function-declaration-Werror=missing-prototypes-Werror=return-type-Werror=vla-Wformat=1-Wno-maybe-uninitialized-std=c11-fdiagnostics-color=auto-ffile-prefix-map=/home/dian/.cache/pikaur/build/proton-ge-custom/src/build/src-ffmpeg=.-fwrapv-fno-strict-aliasing-ffile-prefix-map=/home/dian/.cache/pikaur/build/proton-ge-custom/src/build/src-ffmpeg=.-fomit-frame-pointer-fPIC-fno-math-errno-fno-signed-zeros-fno-tree-vectorize-o-%

patlefort commented on 2022-05-14 04:39 (UTC)

Build is freezing for me at this location:

cd ./libswscale/ && ln -s -f libswscale.so.5 libswscale.so
i686-pc-linux-gnu-strip -x libavcodec/x86/h264_intrapred.o
i686-pc-linux-gnu-strip -x libavcodec/x86/simple_idct.o

It stay there forever, I can see a cc1 process taking cpu time but it never ends.

loathingkernel commented on 2022-04-22 12:24 (UTC) (edited on 2022-04-22 12:25 (UTC) by loathingkernel)

@medzik Thank you for notifying me. I hastily posted the update because I am on vacation. I will try to update with the dependency, in the meantime you can manually add libvpx and lib32-libvpx in the depends array

medzik commented on 2022-04-22 11:07 (UTC)

ERROR: Dependency "vpx" not found, tried pkgconfig and cmake see logs

loathingkernel commented on 2022-04-18 19:42 (UTC) (edited on 2022-04-18 19:43 (UTC) by loathingkernel)

@saburouta it is required by the Proton package to build its fonts.

saburouta commented on 2022-04-18 18:53 (UTC)

Does one of these patches cause the build-step that invokes fontforge? I can build Wine without it. Is it a part of the Proton project itself, or did you add that? Can I disable that build-step somehow?

riod commented on 2022-02-24 15:43 (UTC)

hello, when running sekiro using the latest version of proton-ge-custom built using this package my xbox controller doesn't seem to work. my controller still works fine if i use one of steam's proton versions (i tried 6 and 7) with sekiro and other games using proton-ge-custom do seem able to use my controller. any idea what the problem could be?

nicman23 commented on 2022-02-16 09:28 (UTC)

huh you are right. well i just installed it manually and it worked. sorry to bother you :(

loathingkernel commented on 2022-02-15 11:55 (UTC) (edited on 2022-02-15 11:55 (UTC) by loathingkernel)

@nicman23 It already is in the makedepends. Whatever issue you are having with it, is on your side.

nicman23 commented on 2022-02-15 09:31 (UTC) (edited on 2022-02-15 10:27 (UTC) by nicman23)

please add python-virtualenv to makedepends

loathingkernel commented on 2021-12-28 18:52 (UTC)

@patlefort That patch was a hack at best. The proper solution should be implemented in Steam itself and I have created a relevant bug report (there are a few more bug reports that would eventually achieve the same thing) but it was ignored.

@Freso Because of build failures that I wasn't able to resolve in time for the holidays. I will look into it again when I return to my base.

Freso commented on 2021-12-28 15:17 (UTC)

Why was 7.0rc2-GE-1 rolled back?

patlefort commented on 2021-12-28 03:29 (UTC)

I think the proton-user_compat_data.patch doesn't work with steam's autocloud. The vdf file will still be generated inside the compatdata directory in the target game library folder and saves will not be synced.

Erde commented on 2021-12-04 19:55 (UTC)

It is also trivial to change said behavior, but in that case, caveat emptor. Imho, it is better to have a package that compiles and works for most users and those seeking further customization to make relevant changes, than risk the majority to have changes just to get a working build.

loathingkernel commented on 2021-12-01 13:10 (UTC) (edited on 2021-12-01 17:24 (UTC) by loathingkernel)

@rvalles, I feel strongly that I have explained my rationale for doing so in the pinned comment and the comments in the PKGBUILD itself. I have also explained what is the point of the package in the pinned comment. If you want to address any of these points specifically, feel free to do so but in a less vague manner than the "the Arch way", because there are packages in the repos that do exactly that if it is required.

rvalles commented on 2021-12-01 12:29 (UTC) (edited on 2021-12-01 12:29 (UTC) by rvalles)

I feel strongly that the PKGBUILD should not override my makepkg.conf C[XX]FLAGS. This is not the Arch way.

There's little point to building this relative to -bin if it isn't to target my own machine.

theriddick commented on 2021-11-13 06:49 (UTC)

If I build this; is it grabbing the latest MASTER or just the 19+ day old 6.20-1????

ptr1337 commented on 2021-10-19 09:20 (UTC) (edited on 2021-10-19 09:30 (UTC) by ptr1337)

Prebuilt packages can be found here: https://mirror.cachyos.org/?search=proton

how to add this repo:

https://wiki.cachyos.org/en/home/Repo

The packages are built with x86-64 and the optimized x86-64-v3 if your cpu supports that.

loathingkernel commented on 2021-10-16 22:56 (UTC) (edited on 2021-10-16 23:03 (UTC) by loathingkernel)

@adamant.pwn I could not replicate the failure in a clean fully updated Arch chroot. Odds are that it is something specific to your system.

adamant.pwn commented on 2021-10-16 20:59 (UTC)

I tried compiling it with both yay and makepkg, both resulted in this

FAILED: ext/wayland/libgstwaylandsink.so 
gcc -m32  -o ext/wayland/libgstwaylandsink.so ext/wayland/libgstwaylandsink.so.p/meson-generated_.._viewporter-protocol.c.o ext/wayland/libgstwaylandsink.so.p/meson-generated_.._linux-dmabuf-unstable-v1-protocol.c.o ext/wayland/libgstwaylandsink.so.p/meson-generated_.._fullscreen-shell-unstable-v1-protocol.c.o ext/wayland/libgstwaylandsink.so.p/meson-generated_.._xdg-shell-protocol.c.o ext/wayland/libgstwaylandsink.so.p/gstwaylandsink.c.o ext/wayland/libgstwaylandsink.so.p/wlshmallocator.c.o ext/wayland/libgstwaylandsink.so.p/wlbuffer.c.o ext/wayland/libgstwaylandsink.so.p/wldisplay.c.o ext/wayland/libgstwaylandsink.so.p/wlwindow.c.o ext/wayland/libgstwaylandsink.so.p/wlvideoformat.c.o ext/wayland/libgstwaylandsink.so.p/wllinuxdmabuf.c.o -L/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_orc32/lib -L/home/adamant/AUR/proton-ge-custom/src/build/dst-gstreamer32/lib -L/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_base32/lib -I/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_orc32/include -I/home/adamant/AUR/proton-ge-custom/src/build/dst-gstreamer32/include -I/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_base32/include -flto -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group -Wl,-soname,libgstwaylandsink.so -Wl,-Bsymbolic-functions -Wl,-rpath-link=/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_orc32/lib -Wl,-rpath-link=/home/adamant/AUR/proton-ge-custom/src/build/dst-gstreamer32/lib -Wl,-rpath-link=/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_base32/lib -Wl,-O1,--sort-common,--as-needed -gdwarf-2 -gstrict-dwarf -O3 -march=nocona -mtune=core-avx2 -pipe -mno-avx -mno-avx2 -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/adamant/AUR/proton-ge-custom/src/build/src-gst_bad=. -mstackrealign -gdwarf-2 -gstrict-dwarf -O3 -march=nocona -mtune=core-avx2 -mno-avx -mno-avx2 -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/adamant/AUR/proton-ge-custom/src/build/src-gst_bad=. -mstackrealign '-Wl,-rpath,$ORIGIN/../../gst-libs/gst/wayland' -Wl,-rpath-link,/home/adamant/AUR/proton-ge-custom/src/build/obj-gst_bad32/gst-libs/gst/wayland gst-libs/gst/wayland/libgstwayland-1.0.so.0.1804.0 /home/adamant/AUR/proton-ge-custom/src/build/dst-gstreamer32/lib/libgstreamer-1.0.so /usr/lib32/libgobject-2.0.so /usr/lib32/libglib-2.0.so /home/adamant/AUR/proton-ge-custom/src/build/dst-gst_base32/lib/libgstvideo-1.0.so /home/adamant/AUR/proton-ge-custom/src/build/dst-gstreamer32/lib/libgstbase-1.0.so /home/adamant/AUR/proton-ge-custom/src/build/dst-gst_base32/lib/libgstallocators-1.0.so /usr/lib32/libwayland-client.so /usr/lib32/libdrm.so -Wl,--end-group
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o: in function `gst_wayland_sink_begin_geometry_change':
/usr/include/wayland-client-protocol.h:5881: undefined reference to `wl_proxy_marshal_flags'
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o: in function `gst_wayland_sink_end_geometry_change':
/usr/include/wayland-client-protocol.h:5911: undefined reference to `wl_proxy_marshal_flags'
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o: in function `gst_wl_buffer_finalize':
/usr/include/wayland-client-protocol.h:1998: undefined reference to `wl_proxy_marshal_flags'
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o: in function `gst_wl_buffer_force_release_and_unref':
/usr/include/wayland-client-protocol.h:1998: undefined reference to `wl_proxy_marshal_flags'
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o: in function `handle_xdg_wm_base_ping':
/home/adamant/AUR/proton-ge-custom/src/build/obj-gst_bad32/ext/wayland/xdg-shell-client-protocol.h:541: undefined reference to `wl_proxy_marshal_flags'
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o:/usr/include/wayland-client-protocol.h:3274: more undefined references to `wl_proxy_marshal_flags' follow
collect2: error: ld returned 1 exit status

loathingkernel commented on 2021-09-28 17:15 (UTC) (edited on 2021-09-28 17:20 (UTC) by loathingkernel)

@C0D3-M4513R I have had this happen to other people too but not me. afdko is supposed to be installed through pip as the AUR package used to break regularly. Can you give me some information about your setup or a log to see why this is happening?

Edit: let me guess, you are using yay. yay has the bad habit of not retaining the environment between prepare() and build(). It works with makepkg as intended.

C0D3-M4513R commented on 2021-09-28 16:59 (UTC)

afdko was not a dependency of this package. I had to manually install, since it isn't installed by default.

thaewrapt commented on 2021-09-07 12:21 (UTC)

@loathingkernel My build platform is Core2 without any AVX support, maybe that's the source of the problem.

loathingkernel commented on 2021-09-07 11:51 (UTC) (edited on 2021-09-07 11:58 (UTC) by loathingkernel)

@thaewrapt I am against that idea for two reasons. The default flags specified in makepkg.conf (-march=x86_64) will cause unknowing users to use lesser optimizations than upstream. At this moment these flags are what upstream uses too. If a user decides to edit them or even notices the discrepancy, I would prefer them to take a look at the PKGBUILD before adjusting them, because the reasoning and potential issues are documented there too, for the same reasons that are mentioned in the pinned comment.

That being said it is not clear to me what you are proposing. What should be checked before setting -march?

thaewrapt commented on 2021-09-07 11:42 (UTC)

PS I've read the pinned comment, can we at least add the check if the pre-requisites for -march change are met prior to setting it? I would try to think if there is a better way to work this around, but I cannot think of any right now.

loathingkernel commented on 2021-09-07 11:41 (UTC)

@thaewrapt There are good reasons for doing that, as explained in the pinned comment. Please read them. if you want clarifications to the reasoning I am happy to provide them. What platforms does this cause issues with?

thaewrapt commented on 2021-09-07 11:34 (UTC) (edited on 2021-09-07 11:35 (UTC) by thaewrapt)

Please do not override -march (and probably CFLAGS at all) in PKGBUILD, as it breaks build process on some platforms, rendering this package unusable. If someone would want anything except "generic", it's achievable via /etc/makepkg.conf settings.

loathingkernel commented on 2021-08-19 07:32 (UTC) (edited on 2021-08-19 14:38 (UTC) by loathingkernel)

@qontinuum yeah, the issue with faudio is also the one blocking the update. Adding it as an Arch native dependency won't work, as FAudio on Proton needs FFMpeg support, something that the Arch library lacks for the lib32 package, and can't be used as a drop-in replacement. I have been trying to tackle this very issue for the past few days but I have had no success.

EDIT: The issue is due to lib32-sdl2 lagging behind in the repos. I will withhold updating it until the version in the repos has been updated to 2.0.16

qontinuum commented on 2021-08-19 07:10 (UTC) (edited on 2021-08-19 07:10 (UTC) by qontinuum)

@qfettes check the pinned message, may help to read those

@loathingkernel: I am getting an error with faudio when compiling:

configure: error: libFAudio 32-bit development files not found, XAudio2 won't be supported.
This is an error since --with-faudio was requested.

It isn't fixed by adding lib32-faudio as a dependency but I was able to compile older versions on the package (I am currently running version 1:6.14.GE.2-2).

qfettes commented on 2021-08-17 18:52 (UTC)

Installing with yay aur helper yields the following error:

Could not find all required packages:
    meson=0.58.1

MisterNoNameLP commented on 2021-08-16 11:31 (UTC)

@loathingkernel nah, seems to be fixed now.
sry for the false alarm.

loathingkernel commented on 2021-08-14 13:51 (UTC)

@MisterNoNameLP this has been fixed, are you still getting an error?

MisterNoNameLP commented on 2021-08-14 13:44 (UTC) (edited on 2021-08-14 13:45 (UTC) by MisterNoNameLP)

if anyone still get the error: > ninja: fatal: invalid -j parameter here is a quick and dirty workaround. it basically just removes the -j flag from all ninja calls in a specific terminal.

Dependencies:
lua

(replace PATH_TO_DIR with any path u want to use)
open a terminal and do the following:

mkdir PATH_TO_DIR   #create new dir
touch PATH_TO_DIR/ninja   #create a file named "ninja"
chmod +x PATH_TO_DIR/ninja   #make the file "ninja" executable
export PATH="ABSOLUTE_PATH_TO_DIR:$PATH"   #adds the dir to the $PATH variable, so our file gets called instead of ninja

then open PATH_TO_DIR/ninja with any editor u like and add the following:

#!/bin/lua
--calls ninja witout the -j flag.

local args = ""
for i, a in pairs(arg) do
    if i > 0 then
        args = args .. a .. " "
    end
end
args = args:gsub("-j", "")

return os.execute("/usr/bin/ninja " .. args)

this script calls ninja but without any -j flag.

that should "fix" the problem. but u have to call export PATH="ABSOLUTE_PATH_TO_DIR:$PATH" everytime u are trying to build the package in a new terminal.

ps.: i know that is pretty crappy. but it seems to work in this case so.. shrug

loathingkernel commented on 2021-08-02 14:57 (UTC) (edited on 2021-08-02 14:58 (UTC) by loathingkernel)

Yeah that is a good point.

PedroHLC commented on 2021-08-02 14:54 (UTC) (edited on 2021-08-02 14:57 (UTC) by PedroHLC)

@loathingkernel, it should at least not fail with what is "default" in Arch. So probably a if [[ "$MAKEFLAGS" =~ -j\ *([^\ ]+) ]]; then SUBJOBS="${BASH_REMATCH[1]}" else SUBJOBS="$(nproc)"; fi would be welcomed...

loathingkernel commented on 2021-08-02 14:20 (UTC) (edited on 2021-08-02 14:28 (UTC) by loathingkernel)

I do not want to ignore the makeflags or the buildflags as a whole (although I will concede that I am already overriding a lot of those), but MAKEFLAGS being empty is causing the issue. Ignoring makeflags through options is not going to fix the issue as described in the previous comment (I will still have to specify something there to avoid congestion) and building with 1 job is going to take a very long time.

You can configure the $CHROOT/root to uncomment MAKEFLAGS or I can hard-code $(nproc) as an argument to SUBJOBS. Honestly I have no better solution at this point.

PedroHLC commented on 2021-08-02 14:05 (UTC)

@loathingkernel it's a freshly clean chroot, so MAKEFLAGS is still commented in /etc/makepkg.conf. (I put an echo in prepare to spy it anyway, and Arch's default seems to be indeed empty).

What about using options+=(!buildflags !makeflags) ?

More useful in its negative form !buildflags with select packages that have problems building with custom buildflags.

More useful in its negative form !makeflags with select packages that have problems building with custom makeflags such as -j2 (or higher).

loathingkernel commented on 2021-08-02 13:57 (UTC) (edited on 2021-08-02 14:22 (UTC) by loathingkernel)

What is in your MAKEFLAGS? I am not doing any filtering, so the specified value after -j can be the problem. Could you hardcode the SUBJOBS variable in the PKGBUILD to any value you would like and try again?

The thing is if I revert to how the original makefile is doing it, different subprojects get built at the same time so logging is interleaved. Also every meson subproject will spawn an equal amount of jobs as there is no communication between the makefile and the meson build systems.

That being said, I will try to filter MAKEFLAGS if that is the issue.

PedroHLC commented on 2021-08-02 13:33 (UTC)

Downgraded meson, but:

:: building 32bit gst_orc...
env CARGO_HOME=/home/main-builder/pkgwork/src/build/.cargo CARGO_TARGET_I686_UNKNOWN_LINUX_GNU_LINKER="gcc" CARGO_TARGET_I686_UNKNOWN_LINUX_GNU_RUSTFLAGS="" CCACHE_BASEDIR="/home/main-builder/pkgwork/src/build/src-gst_orc" STRIP="strip" CC=" gcc -m32" CXX=" g++ -m32" LD="i686-linux-gnu-ld" PKG_CONFIG="i686-pc-linux-gnu-pkg-config" CROSSCC=" i686-w64-mingw32-gcc" CROSSCXX=" i686-w64-mingw32-g++" CROSSLD="i686-w64-mingw32-ld" CROSSPKG_CONFIG="i686-pc-linux-gnu-pkg-config" PATH=":/home/main-builder/pkgwork/src/proton-ge-custom/glslang/bin:$PATH" LD_LIBRARY_PATH="$LD_LIBRARY_PATH" PKG_CONFIG_PATH="" CFLAGS="  -gdwarf-2 -gstrict-dwarf -O3 -march=nocona -mtune=core-avx2 -pipe -mno-avx -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/main-builder/pkgwork/src/build/src-gst_orc=. -mstackrealign" CXXFLAGS="  -gdwarf-2 -gstrict-dwarf -O3 -march=nocona -mtune=core-avx2 -pipe -mno-avx -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/main-builder/pkgwork/src/build/src-gst_orc=. -mstackrealign -std=c++17" LDFLAGS="   -Wl,-O1,--sort-common,--as-needed" ninja -j -C "/home/main-builder/pkgwork/src/build/obj-gst_orc32" install -v
ninja: fatal: invalid -j parameter
make[2]: *** [../proton-ge-custom/build/makefile_base.mak:435: /home/main-builder/pkgwork/src/build/.gst_orc-build32] Error 1

Erde commented on 2021-07-19 16:40 (UTC)

Thanks for the update!

Erde commented on 2021-07-15 13:33 (UTC)

While we are waiting for loathingkernel to find time to update the PKGBUILD, anyone managed to make a functioning one for the latest Proton GE version that they could share with me? Tried to edit the PKGBUILD myself, but what was required was beyond my ability as it wasn't just as simple as changing commits and such. Would appreciate it.

In the mean time, people might be interested to know that an prebuilt alternative also exists on AUR, though it's build against steam linux runtime if I am not mistaken.

loathingkernel commented on 2021-06-08 07:21 (UTC) (edited on 2021-06-08 07:23 (UTC) by loathingkernel)

@markkuit yes, it would be absolutely fine to edit it out until you have pacman 6. I cannot comment on any other potential issues from reading the thread you linked.

markkuit commented on 2021-06-08 07:12 (UTC)

@loathingkernel thank you; for Manjaro users passing by, it looks like pacman is still at v5 due to ongoing pamac porting (see forum thread for more info).

Would it be safe (and working) to edit out the !lto option from the PKGBUILD when building, as a temporary fix for the time being?

loathingkernel commented on 2021-06-08 07:03 (UTC) (edited on 2021-06-08 07:03 (UTC) by loathingkernel)

@markkuit yes, you are missing core/pacman 6.0.0-2

markkuit commented on 2021-06-08 06:39 (UTC)

With the addition of !lto in the options array in commit f304e64fbdfa ("Fix compilation error due to missing <optional> include"), this fails at the very beginning with: ==> ERROR: options array contains unknown option '!lto'.

This is on Manjaro, libalpm v12.0.2, Pacman v5.2.2, tried with Pamac 10.0.6-2 and yay v10.2.2. Am I missing something?

loathingkernel commented on 2021-06-07 17:25 (UTC) (edited on 2021-06-07 17:25 (UTC) by loathingkernel)

@Nullrequest afdko should be installed by pip during the prepare step, I have confirmed this multiple times. Is there any special configuration around your system? Can you post a link to your build log?

randomguy343 commented on 2021-06-07 17:05 (UTC)

You need the afdko package.

Nullrequest commented on 2021-06-07 15:24 (UTC) (edited on 2021-06-07 15:24 (UTC) by Nullrequest)

I am having a make issue where it fails with makeotf: command not found any idea why?

loathingkernel commented on 2021-06-03 16:14 (UTC)

The compile error should be fixed now.

Freso commented on 2021-06-02 19:31 (UTC)

Using Arch Linux, right after a fresh pacman -Syu, in a directory with a clean and fresh checkout of https://aur.archlinux.org/proton-ge-custom.git (ie., no altered C{,XX}FLAGS), running makepkg -fscCi results in this for me: http://sprunge.us/nTgGKj

stdinUsrError commented on 2021-06-02 01:09 (UTC)

After installing lld and today's commit that fixed the issue with the dxvk repo I'm happy to report the AUR build completed successfully for me with pamac on Manjaro.

@loathingkernel Thanks for getting the issues sorted and maintaining this package!

loathingkernel commented on 2021-05-31 21:08 (UTC)

@randomguy343 I just updated it to pull the latest commit. But I do not want to to push it without testing it. You can grab the files from here and build it with makepkg. If it works, I will update the AUR versions.

randomguy343 commented on 2021-05-31 19:06 (UTC)

Thanks for looking into it and no hurry, the Github releases are also easy to use in the mean time.

loathingkernel commented on 2021-05-31 16:18 (UTC) (edited on 2021-05-31 16:19 (UTC) by loathingkernel)

@randomguy343 Yeah, that is an issue with the github repo actually. It is weird, the commit exists but it is not part of any branch, so it doesn't get fetched. I am reluctant to re-target the dxvk submodule as GE applies patches on DXVK and I don't want to have to untangle any potential mess and I do not want to pin it. Generally with every release the submodule gets re-targeted. I will look into it when I find some time and see what I can do. Thanks for bringing it to my attention.

randomguy343 commented on 2021-05-31 14:52 (UTC) (edited on 2021-05-31 14:57 (UTC) by randomguy343)

When installing using the AUR helper yay I get the following error, so I suppose it's a problem with the dxvk submodule's URL?
Thanks in advance for maintaining this package and helping with all the issues.


fatal: git upload-pack: not our ref 45cd4ce26882a07a4aca90fd771117789237e636
fatal: error at other end: upload-pack: not our ref 45cd4ce26882a07a4aca90fd771117789237e636
"fetch" in submodule-path 'dxvk' executed, but 45cd4ce26882a07a4aca90fd771117789237e636 not included.
Directly requesting this commit failed.
==> ERROR: An error happened in prepare().
Aborting...
error making: proton-ge-custom

loathingkernel commented on 2021-05-30 09:43 (UTC)

@Dennis, thanks for figuring it out. I will add it as a dependency.

dekatria commented on 2021-05-30 08:22 (UTC) (edited on 2021-05-30 08:22 (UTC) by dekatria)

Can confirm, installing lld fixed it for me as well.

Thanks @Dennis for finding the solution. Thanks @loathingkernel for helping with the issue as well; will be more descriptive when reporting issues in the future.

Dennis commented on 2021-05-30 02:06 (UTC)

Fixed it: Digging into "src/build/src-wine/tools/winegcc/winegcc.c" I figured out that it looks for a very specific version of the linker ld, namely ld.lld (see line 359 in winegcc.c), which is provided by the package "https://archlinux.org/packages/extra/x86_64/lld/". After installing the lld package, the build succeeds on my system. It might be a good idea to add the lld package as a dependency. Perhaps that will help the Manjaro users as well.

Dennis commented on 2021-05-29 17:59 (UTC)

@loathingkernel: Well, I posted the only error in the log and not the whole log and I did not think it would be necessary to state explicitly that I am on Arch while posting about something inside a repository named "Arch User Repository". I am also not doing anything special going about the build. I download the snapshot, I extract it, I run makepkg. I will continue trying to build and report if I can figure out how to fix and what's causing it.

loathingkernel commented on 2021-05-29 17:46 (UTC) (edited on 2021-05-29 17:50 (UTC) by loathingkernel)

@Dennis I consider it an insult and bad faith to dumb a badly formatted, information lacking log without providing any other details about an issue that has been already discussed in the past 2-3 pages of comments. If you have had looked at the comments then it would be clear that you should have mentioned at least that it is happening to you on Arch. Yes, I have seen that error, I have had discussions in this very comment space about that error. And I have already replied that I cannot reproduce it for the other few times. And I tried again, didn't happen either.

So yeah, I will suggest that you didn't do your due diligence before reporting it. The rest of it, about suggesting you are dumb or anything, it is your interpretation and not what I said.

Dennis commented on 2021-05-29 17:27 (UTC)

@loathingkernel: The only thing fishy here seems to be your attitude. I did absolutely nothing to offend you and yet everything starting from your first reply is suggesting that I'm dense or stupid or whatever. Anyway, if you can't help, then don't respond but please refrain from throwing more suggestive/insultive "you're just too dumb" bullshit my way.

loathingkernel commented on 2021-05-29 17:01 (UTC)

@Dennis, excuse me, but I did a rebuild today on a fully upgraded Arch system in a clean chroot, and I have done so the last 4 times this error has been reported. Somehow I doesn't manifest, not once. Every instance of this error so far has been from Manjaro users. I do not know how you are building it, where you are building it, and what the rest of the log looks like as you didn't post it. Also, if you had looked, you would see that request to not post logs but link to them, as in a pastebin-like service, so I doubt you read them before I mentioned it. Something is definately fishy here.

Dennis commented on 2021-05-29 16:51 (UTC)

@loathingkernel: [dennis@DB2arch ~]$ distro Name: Arch Linux Version: rolling (n/a) Codename: n/a Excuse me but I did read the pinned message and I could not find any solution to the error in the existing comments. I did a full system upgrade just before attempting the build to make sure everything is up-to-date.

loathingkernel commented on 2021-05-29 16:34 (UTC)

@Dennis, let me guess, Manjaro and you didn't bother to look at the rest of the comments nor the pinned message right?

Dennis commented on 2021-05-29 16:20 (UTC) (edited on 2021-05-29 16:21 (UTC) by Dennis)

Build fails for me while trying to build capi2032.dll.so. Any ideas what might be causing that and how to fix?

tools/winegcc/winegcc -o dlls/capi2032/capi2032.dll.so --wine-objdir . -m32 -fno-PIC -Wl,-z,notext \ -fasynchronous-unwind-tables -shared \ /mnt/RAM/proton-ge-custom/src/build/src-wine/dlls/capi2032/capi2032.spec dlls/capi2032/cap20wxx.o \ libs/port/libwine_port.a -ldl -L/mnt/RAM/proton-ge-custom/src/build/dst-gst_orc32/lib -L/mnt/RAM/proton-ge-custom/src/build/dst-gstreamer32/lib -L/mnt/RAM/proton-ge-custom/src/build/dst-gst_base32/lib -L/mnt/RAM/proton-ge-custom/src/build/dst-faudio32/lib -L/mnt/RAM/proton-ge-custom/src/build/dst-jxrlib32/lib -Wl,-rpath-link=/mnt/RAM/proton-ge-custom/src/build/dst-gst_orc32/lib -Wl,-rpath-link=/mnt/RAM/proton-ge-custom/src/build/dst-gstreamer32/lib -Wl,-rpath-link=/mnt/RAM/proton-ge-custom/src/build/dst-gst_base32/lib -Wl,-rpath-link=/mnt/RAM/proton-ge-custom/src/build/dst-faudio32/lib -Wl,-rpath-link=/mnt/RAM/proton-ge-custom/src/build/dst-jxrlib32/lib -Wl,-O1,--sort-common,--as-needed winegcc: Could not find ld make[3]: *** [Makefile:20626: dlls/capi2032/capi2032.dll.so] Error 2 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory '/mnt/RAM/proton-ge-custom/src/build/obj-wine32' make[2]: *** [../proton-ge-custom/build/makefile_base.mak:723: /mnt/RAM/proton-ge-custom/src/build/.wine-build32] Error 2 make[2]: Leaving directory '/mnt/RAM/proton-ge-custom/src/build' make[1]: *** [../proton-ge-custom/build/makefile_base.mak:89: container-build] Error 2 make[1]: Leaving directory '/mnt/RAM/proton-ge-custom/src/build' make: *** [../proton-ge-custom/build/makefile_base.mak:20: nested_make] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

loathingkernel commented on 2021-05-29 10:47 (UTC)

The new version retargeted the the dxvk submodule and it seems to be fixed now.

dekatria commented on 2021-05-29 04:06 (UTC) (edited on 2021-05-29 04:09 (UTC) by dekatria)

@dragostini try setting the remote and pulling the commit to the makepkg branch

edit:

cd /var/tmp/pamac-build-dragostini/proton-ge-custom/src/proton-ge-custom/dxvk
git remote set-url origin https://github.com/doitsujin/dxvk.git
git pull origin d707c2eacd233876c82842fc79cda7b336a1f80d

dragostini commented on 2021-05-28 18:18 (UTC)

@loathingkernel

Unfortunately my experience is a bit limited on git/github. I use it daily for work, but not in any way that would help you figure this out :(

loathingkernel commented on 2021-05-28 18:16 (UTC)

The commit exists on github. I have no idea why it is happening.

dragostini commented on 2021-05-28 18:04 (UTC)

@loathingkernel

I had done a fresh clone in a totally newly created directory, just to be safe.

loathingkernel commented on 2021-05-28 17:57 (UTC) (edited on 2021-05-28 17:59 (UTC) by loathingkernel)

@dragostini did you delete the existing clones?

EDIT: Hmm, nevermind, I just hit it too in a fresh clone. My archived clones had that commit.

dragostini commented on 2021-05-28 17:55 (UTC) (edited on 2021-05-28 17:56 (UTC) by dragostini)

@loathingkernel

built via terminal (git clone manually and makepkg -si) and it still borked. Same error.

fatal: git upload-pack: not our ref d707c2eacd233876c82842fc79cda7b336a1f80d

fatal: remote error: upload-pack: not our ref d707c2eacd233876c82842fc79cda7b336a1f80d

Fetched in submodule path 'dxvk', but it did not contain d707c2eacd233876c82842fc79cda7b336a1f80d. Direct fetching of that commit failed.

==> ERROR: A failure occurred in prepare().

Aborting...

[dragostini@crusnic01 proton-ge-custom]$

loathingkernel commented on 2021-05-28 17:48 (UTC)

@dragostini That means that the commit the submodule is pointing to cannot be found. There are two reasons for it to happen, either it was deleted or the git clone was a shallow one. According to github the commit exists. Try again with makepkg and see if it happens.

dragostini commented on 2021-05-28 17:41 (UTC) (edited on 2021-05-28 17:45 (UTC) by dragostini)

@loathingkernel

Getting this:

Cloning into '/var/tmp/pamac-build-dragostini/proton-ge-custom/src/proton-ge-custom/dxvk'...

done.

fatal: git upload-pack: not our ref d707c2eacd233876c82842fc79cda7b336a1f80d

fatal: remote error: upload-pack: not our ref d707c2eacd233876c82842fc79cda7b336a1f80d

Fetched in submodule path 'dxvk', but it did not contain d707c2eacd233876c82842fc79cda7b336a1f80d. Direct fetching of that commit failed. ==> ERROR: A failure occurred in prepare().

Aborting...

Running Arch (technically EndeavourOS, but that is 99% pure Arch so I don't see how it should be an issue.)

Using Pamac for GUI AUR access / helper

stdinUsrError commented on 2021-05-28 16:16 (UTC)

@loathingkernel I actually tried both a full update to staging and just updating gcc and libraries after the git error. Same on both unfortunately. Last update to stable was on the 19th and they push updates looks like about every week and a half, so hopefully it'll hit in the next few days.

loathingkernel commented on 2021-05-28 16:09 (UTC)

@stdinUsrError The error with cloning DXVK could be unrelated, or it could be related if you didn't do a full update on your system and just installed gcc. If you only installed gcc and its libs, you did what we call a partial update and your system might break in unexpected ways. Either do an update to Manjaro staging or revert to Manjaro stable and wait for it to catch up to Arch.

stdinUsrError commented on 2021-05-28 15:47 (UTC)

After doing some digging it appears that gcc 11.1 has not made its way to the stable branch for Manjaro. It is still in staging. I updated gcc and relevant libraries to 11.1 from the staging branch and reran the AUR build, however it appears I'm now getting a git reference error when cloning dxvk. How odd. Next step would be either building gcc 11.1 myself or waiting for it to show up in stable. Busy holiday weekend for me so probably going to wait a few days. Strongly considering making the switch to Arch though. lol.

@loathingkernel Thanks for your help and insight on this. I'll report back next week with my findings for any Manjaro users who might be following along.

loathingkernel commented on 2021-05-27 18:08 (UTC) (edited on 2021-05-27 18:09 (UTC) by loathingkernel)

@stdinUsrError Mainline Arch is on core/gcc 11.1.0-1 and community/mingw-w64-gcc 10.2.0-2 so there is a discrepancy there. I do not know what packages had to be rebuilt due to gcc 11 but there is definitely something broken with Manjaro. That is not something I can do anything about. Wine is not and it should not be required. Also it should not be conflicting in any way. That is why I asked and it seems that it doesn't based on yours and mine testing alike.

stdinUsrError commented on 2021-05-27 17:32 (UTC)

@loathingkernel Pacman reports 10.2.0-2 for mingw-w64-gcc and 10.2.0-6 for gcc.

Wine is not currently installed but I have tried the AUR build separately with both wine and wine-staging installed as well. As far as I could tell results did not differ. Pacman reports version 6.8-1 for both currently.

loathingkernel commented on 2021-05-27 16:38 (UTC)

@stdinUsrError If I had to guess, it has to do with Manjaro holding some package versions back, but they do not hold everything. They might have held mingw-gcc or gcc and created an ABI incompatibility. It might be something else. What you could post here are the versions of mingw-gcc, gcc, and if wine is installed, the version of that (I have a hunch that I want to test).

stdinUsrError commented on 2021-05-27 15:57 (UTC)

@loathingkernel Sorry I didn't think to mention my distro, thats my bad. You mentioned pamac so I tried building with yay, same error. Any thoughts on what the "could not find ld" error might point to so I can work on figuring out what's going on on my end?

loathingkernel commented on 2021-05-27 14:33 (UTC) (edited on 2021-05-27 14:40 (UTC) by loathingkernel)

@stdinUsrError You can just run makepkg after the cloning this AUR repo.

I did have a feeling you were on Manjaro as well as the other people that reported this issue (pamac in the logs). I don't know what shitty things the distro you are using might be doing but I do not test against them. And I sure as hell won't try to guess what they might be doing wrong. It builds just fine on mainline Arch.

The least you can do is mention it when reporting the issue, the build takes quite some time and resources and every time someone reports an issue I try to reproduce it. I consider it common courtesy to mention it and not letting me guess.

stdinUsrError commented on 2021-05-27 14:24 (UTC)

@loathingkernel Negative. There's a lot going on here and tbh I'm not sure how comfortable I am building it on my own. I could probably give it a shot later tonight though. I'm on Manjaro.

loathingkernel commented on 2021-05-27 14:06 (UTC)

@stdinUsrError @biorpg Has either of you tried building without an AUR helper and what distro are you on?

stdinUsrError commented on 2021-05-27 13:54 (UTC) (edited on 2021-05-27 13:56 (UTC) by stdinUsrError)

I too am seeing the "winegcc: Could not find ld" error every time when it gets to the dlls. My log output looks identical to biorpg's with it failing when it hits capi2032.dll.so.

I've double checked all my dependencies and as far as I can tell everything that needs to be is there. I've tried updating and removing and reinstalling multiple times. Build has been failing I believe since the 6.5 update. All steam proton-ge prefixes have been removed per GE's recommendations. I'm at a loss for how to proceed as I'm not really finding anything online about how to handle this error.

biorpg commented on 2021-05-27 04:21 (UTC)

I am also getting the 'winegcc: Could not find ld' error.

tools/winegcc/winegcc -o dlls/capi2032/capi2032.dll.so --wine-objdir . -m32 -fno-PIC -Wl,-z,notext \
  -fasynchronous-unwind-tables -shared \
  /var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/src-wine/dlls/capi2032/capi2032.spec \
  dlls/capi2032/cap20wxx.o libs/port/libwine_port.a -ldl -L/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gst_orc32/lib -L/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gstreamer32/lib -L/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gst_base32/lib -L/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-faudio32/lib -L/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-jxrlib32/lib -Wl,-rpath-link=/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gst_orc32/lib -Wl,-rpath-link=/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gstreamer32/lib -Wl,-rpath-link=/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gst_base32/lib -Wl,-rpath-link=/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-faudio32/lib -Wl,-rpath-link=/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-jxrlib32/lib  -Wl,-O1,--sort-common,--as-needed 
winegcc: Could not find ld
make[3]: *** [Makefile:20944: dlls/capi2032/capi2032.dll.so] Error 2
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/obj-wine32'
make[2]: *** [../proton-ge-custom/build/makefile_base.mak:723: /var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/.wine-build32] Error 2
make[2]: Leaving directory '/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build'
make[1]: *** [../proton-ge-custom/build/makefile_base.mak:89: container-build] Error 2
make[1]: Leaving directory '/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build'
make: *** [../proton-ge-custom/build/makefile_base.mak:20: nested_make] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

It has failed like this 3 or 4 times now, and each time it seems to fail on a different target, but always within the dlls/ folder.

>make[3]: *** [Makefile:20944: dlls/capi2032/capi2032.dll.so] Error 2

loathingkernel commented on 2021-05-22 09:32 (UTC) (edited on 2021-05-22 09:34 (UTC) by loathingkernel)

The build is still running but it got past wine just fine. Check that you have all the prerequisites such as base and base-devel installed as well as updated to stable repos. I do not test with testing.

dekatria commented on 2021-05-22 09:14 (UTC) (edited on 2021-05-22 09:14 (UTC) by dekatria)

I trying to update the package using trizen, it just runs the PKGBUILD for 6.8-GE-2 proton-ge-custom: 1:6.5.GE.2-2 ==> 1:6.8.GE.2-2

loathingkernel commented on 2021-05-22 09:02 (UTC) (edited on 2021-05-22 09:04 (UTC) by loathingkernel)

How are you building the package? winegcc couldn't find ld, something is likely broken with your Arch install. I am going to run a build locally to verify.

dekatria commented on 2021-05-22 08:37 (UTC)

I seem to be facing a missing dependency when trying to build obj-wine32, anyone know how to solve this issue?

tools/winegcc/winegcc -o dlls/dwrite/dwrite.so --wine-objdir . -m32 -fno-PIC -Wl,-z,notext \
  -fasynchronous-unwind-tables -munix -shared \
  ../proton-ge-custom/src/build/src-wine/dlls/dwrite/dwrite.spec \
  dlls/dwrite/freetype.o -lntdll dlls/winecrt0/libwinecrt0.a libs/port/libwine_port.a -ldl \
  -L../proton-ge-custom/src/build/dst-gst_orc32/lib -L../proton-ge-custom/src/build/dst-gstreamer32/lib -L../proton-ge-custom/src/build/dst-gst_base32/lib -L../proton-ge-custom/src/build/dst-faudio32/lib -L../proton-ge-custom/src/build/dst-jxrlib32/lib -Wl,-rpath-link=../proton-ge-custom/src/build/dst-gst_orc32/lib -Wl,-rpath-link=../proton-ge-custom/src/build/dst-gstreamer32/lib -Wl,-rpath-link=../proton-ge-custom/src/build/dst-gst_base32/lib -Wl,-rpath-link=../proton-ge-custom/src/build/dst-faudio32/lib -Wl,-rpath-link=../proton-ge-custom/src/build/dst-jxrlib32/lib  -Wl,-O1,--sort-common,--as-needed
winegcc: Could not find ld
make[3]: *** [Makefile:141216: dlls/dnsapi/dnsapi.so] Error 2
make[3]: *** Waiting for unfinished jobs....
winegcc: Could not find ld
make[3]: *** [Makefile:150417: dlls/dwrite/dwrite.so] Error 2
In file included from include/propidl.h:56,
                 from ../proton-ge-custom/src/build/src-wine/include/objbase.h:512,
                 from ../proton-ge-custom/src/build/src-wine/include/ole2.h:25,
                 from include/dhtmled.h:13,
                 from ../proton-ge-custom/src/build/src-wine/dlls/dhtmled.ocx/edit.c:22:
../proton-ge-custom/src/build/src-wine/dlls/dhtmled.ocx/edit.c: In function ‘DHTMLEdit_GetIDsOfNames’:
include/oaidl.h:1541:12: warning: ‘ti’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 1541 |     return This->lpVtbl->GetIDsOfNames(This,rgszNames,cNames,pMemId);
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../proton-ge-custom/src/build/src-wine/dlls/dhtmled.ocx/edit.c:347:16: note: ‘ti’ was declared here
  347 |     ITypeInfo *ti;
      |                ^~
In file included from include/propidl.h:56,
                 from ../proton-ge-custom/src/build/src-wine/include/objbase.h:512,
                 from ../proton-ge-custom/src/build/src-wine/include/ole2.h:25,
                 from include/dhtmled.h:13,
                 from ../proton-ge-custom/src/build/src-wine/dlls/dhtmled.ocx/edit.c:22:
../proton-ge-custom/src/build/src-wine/dlls/dhtmled.ocx/edit.c: In function ‘DHTMLEdit_Invoke’:
include/oaidl.h:1544:12: warning: ‘ti’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 1544 |     return This->lpVtbl->Invoke(This,pvInstance,memid,wFlags,pDispParams,pVarResult,pExcepInfo,puArgErr);
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../proton-ge-custom/src/build/src-wine/dlls/dhtmled.ocx/edit.c:363:16: note: ‘ti’ was declared here
  363 |     ITypeInfo *ti;
      |                ^~
make[2]: *** [../proton-ge-custom/build/makefile_base.mak:723: ../proton-ge-custom/src/build/.wine-build32] Error 2
make[1]: *** [../proton-ge-custom/build/makefile_base.mak:89: container-build] Error 2

PedroHLC commented on 2021-05-18 23:46 (UTC)

Or check with "which"+"pacman -Qo" if the pip executable comes from python-pip...

loathingkernel commented on 2021-05-18 22:40 (UTC)

Then that was it. Thanks for figuring out the issue. I will see how I can warn users about it. Maybe force-failling the build if pip install fails.

gyscos commented on 2021-05-18 22:38 (UTC)

It happened when I had afdko installed system-wide (maybe it could have interfered with the pip install?). After removing afdko system-wide, it worked fine.

loathingkernel commented on 2021-05-18 21:08 (UTC) (edited on 2021-05-18 22:41 (UTC) by loathingkernel)

pefile should be installed through pip at this line and it is only a build time dependency. If afdko worked it is weird for pefile to fail. I will look again as there are a few more under the radar issues with the build. Due to changes in wine file structure, broken symlinks are copied on updated prefixes. I am testing a fix right now.

gyscos commented on 2021-05-18 20:44 (UTC)

I think the build now depends on python-pefile:

Traceback (most recent call last):
  File "/run/user/60039/paru/clone/proton-ge-custom/src/proton-ge-custom/make/pefixup.py", line 6, in <module>
    import pefile
ModuleNotFoundError: No module named 'pefile'
make[1]: *** [../proton-ge-custom/build/makefile_base.mak:641: /run/user/60039/paru/clone/proton-ge-custom/src/build/.lsteamclient-fixup32] Error 123
make[1]: Leaving directory '/run/user/60039/paru/clone/proton-ge-custom/src/build'
make: *** [../proton-ge-custom/build/makefile_base.mak:20: nested_make] Error 2

loathingkernel commented on 2021-05-18 17:56 (UTC)

I encountered that issue with openexr myself, while updating the PKGBUILD and I decided to force-disable it as it doesn't seem particularly useful, just something that can be found in a non-chroot compilation. For me the new version builds successfully albeit it still needs some beautification work. I will update the PKGBUILD later today if everthing goes smoothly.

gyscos commented on 2021-05-18 15:29 (UTC) (edited on 2021-05-18 15:32 (UTC) by gyscos)

I guess openexr is an optional build dependency for the bundled gst-plugins-bad? (EDIT: seems like it) That'd be why if installed system-wide, gst-plugins-bad will try (and fail) to compile support for it, but it not installed, gst-plugins-bad will just skip it? In that case it may be better to force-disable this, rather than rely on auto-detection.

Though in my case after uninstalling openexr, building this package did go further, but failed building OpenXR-loader instead, with undefined references to std::experimental::filesystem. Will update later with the error message...

loathingkernel commented on 2021-05-17 21:00 (UTC)

There is no bundled version, at least not in the form of a submodule. This could be fixed in the latest version. I will look into updating to that once I have a bit of spare time. Downgrading is not an option as a few other things depend on it from the official repos.

gyscos commented on 2021-05-17 20:33 (UTC)

Does not seem to compile when openexr 3.0.1-2 (from the official repository) is installed.

../../proton-ge-custom/gst-plugins-bad/ext/openexr/gstopenexrdec.cpp: At global scope:
../../proton-ge-custom/gst-plugins-bad/ext/openexr/gstopenexrdec.cpp:45:11: error: ‘Int64’ does not name a type; did you mean ‘gint64’?
   45 |   virtual Int64 tellg ();
      |           ^~~~~
      |           gint64

(openexr 3.0 replaced Int64 with int64_t).

Should it try to compile using a bundled version?

superboringdev commented on 2021-04-28 21:15 (UTC) (edited on 2021-04-28 21:18 (UTC) by superboringdev)

Thanks. I changed it to -march=native -mtune=native -O3, I think that should be as good as it can get, right? -march=nocona -mtune=core-avx2 is pretty old

EDIT: I'm using an i7-4770 which is Haswell architecture.

loathingkernel commented on 2021-04-28 20:47 (UTC) (edited on 2021-04-28 20:50 (UTC) by loathingkernel)

Glad to hear it built correctly. The PKGBUILD is rather messy with the pinned versions and the global makeflags but it made me realize something I had forgot. Later on I have commented the CFLAGS and CXXFLAGS as specified by upstream. Since you are building with basic x86_64 as your -march you might want to enable them to be at least on par with that upstream in terms of performance.

superboringdev commented on 2021-04-28 20:39 (UTC)

Yup, I think I misinterpreted what the PKGBUILD was doing. Anyway, it finished building. Here's my dirty PKGBUILD, if that helps:

# Maintainer: loathingkernel <loathingkernel _a_ gmail _d_ com>

pkgname=proton-ge-custom
_srctag=6.4-GE-1
_commit=c595f7e8b1f3910185dba422d1a94599878f2bc5
pkgver=${_srctag//-/.}
_geckover=2.47.1
_monover=5.1.1
pkgrel=2
epoch=1
pkgdesc="Compatibility tool for Steam Play based on Wine and additional components. GloriousEggroll's custom build"
arch=(x86_64)
url="https://github.com/GloriousEggroll/proton-ge-custom"
license=('custom')
depends=(
  fontconfig      lib32-fontconfig
  lcms2           lib32-lcms2
  libxml2         lib32-libxml2
  libxcursor      lib32-libxcursor
  libxrandr       lib32-libxrandr
  libxdamage      lib32-libxdamage
  libpulse        lib32-libpulse
  gsm             lib32-gsm
  libxi           lib32-libxi
  gettext         lib32-gettext
  freetype2       lib32-freetype2
  glu             lib32-glu
  libsm           lib32-libsm
  gcc-libs        lib32-gcc-libs
  libpcap         lib32-libpcap
  desktop-file-utils
  python
  steam-native-runtime
  cabextract
)
makedepends=(autoconf ncurses bison perl fontforge flex mingw-w64-gcc
  mingw-w64-tools
  meson
  cargo
  rust                  lib32-rust-libs
  giflib                lib32-giflib
  libpng                lib32-libpng
  gnutls                lib32-gnutls
  libxinerama           lib32-libxinerama
  libxcomposite         lib32-libxcomposite
  libxmu                lib32-libxmu
  libxxf86vm            lib32-libxxf86vm
  libldap               lib32-libldap
  mpg123                lib32-mpg123
  openal                lib32-openal
  v4l-utils             lib32-v4l-utils
  libpulse              lib32-libpulse
  alsa-lib              lib32-alsa-lib
  libxcomposite         lib32-libxcomposite
  mesa                  lib32-mesa
  mesa-libgl            lib32-mesa-libgl
  opencl-icd-loader     lib32-opencl-icd-loader
  libxslt               lib32-libxslt
  gst-plugins-base-libs lib32-gst-plugins-base-libs
  vulkan-icd-loader     lib32-vulkan-icd-loader
  sdl2                  lib32-sdl2
  libgphoto2
  sane
  gsm
  vulkan-headers
  samba
  opencl-headers
  git
  cmake
  python-virtualenv
  python-pip
  nasm
  glslang
)
optdepends=(
  giflib                lib32-giflib
  libpng                lib32-libpng
  libldap               lib32-libldap
  gnutls                lib32-gnutls
  mpg123                lib32-mpg123
  openal                lib32-openal
  v4l-utils             lib32-v4l-utils
  alsa-plugins          lib32-alsa-plugins
  alsa-lib              lib32-alsa-lib
  libjpeg-turbo         lib32-libjpeg-turbo
  libxcomposite         lib32-libxcomposite
  libxinerama           lib32-libxinerama
  opencl-icd-loader     lib32-opencl-icd-loader
  libxslt               lib32-libxslt
  gst-plugins-base-libs lib32-gst-plugins-base-libs
  sdl2                  lib32-sdl2
  speex                 lib32-speex
  opus                  lib32-opus
  libgphoto2
  sane
  gsm
  cups
  samba           dosbox
)
makedepends=(${makedepends[@]} ${depends[@]})
#install=${pkgname}.install
source=(
    proton-ge-custom::git+https://github.com/xdevs23/proton-ge-custom.git#commit=${_commit}
    wine::git://source.winehq.org/git/wine.git#commit=41df83c50e1c3cfdd6e8ffb65de7838f8503632c
    wine-staging::git+https://github.com/wine-staging/wine-staging.git#commit=f8b6fde40c2cafda9ffedd0944065177952a16d4
    vkd3d-proton::git+https://github.com/HansKristian-Work/vkd3d-proton.git#commit=b7dfa99e57c8ddad83b513bdc843ccb4c0860d95
    dxvk::git+https://github.com/doitsujin/dxvk.git#commit=cf4ff820be2354efa30aa19a655643b908d6622d
    openvr::git+https://github.com/ValveSoftware/openvr.git#commit=52065df3d6f3af96300dac98cdf7397f26abfcd7
    OpenXR-SDK::git+https://github.com/KhronosGroup/OpenXR-SDK.git#commit=5197afbf199c026eca82a47a8573ed10b0c6fa4e
    ffmpeg::git+https://git.ffmpeg.org/ffmpeg.git#commit=192d1d34eb3668fa27f433e96036340e1e5077a0
    liberation-fonts::git+https://github.com/liberationfonts/liberation-fonts.git
    SPIRV-Headers::git+https://github.com/KhronosGroup/SPIRV-Headers.git
    Vulkan-Headers::git+https://github.com/KhronosGroup/Vulkan-Headers.git
    dxil-spirv::git+https://github.com/HansKristian-Work/dxil-spirv.git
    FAudio::git+https://github.com/FNA-XNA/FAudio.git#commit=920d2228c982f9a2f97276f2e51fbf8ed507963c
    protonfixes-gloriouseggroll::git+https://github.com/gloriouseggroll/protonfixes.git#commit=7ed0543bb118094cf10a61364b7917127f855187
    lsteamclient-gloriouseggroll::git+https://github.com/gloriouseggroll/lsteamclient.git#commit=f5e6dde79cdb255df2c78649db064587cc7f395f
    vrclient_x64-gloriouseggroll::git+https://github.com/gloriouseggroll/vrclient_x64.git#commit=efa15adf7c41b35d8541c346e8a1bfd800428d0a
    gstreamer::git+https://gitlab.freedesktop.org/gstreamer/gstreamer.git#commit=a42fe476d3ee5576921f67a331464065ec33b9a4
    gst-orc::git+https://gitlab.freedesktop.org/gstreamer/orc.git#commit=629864f073ae003e63c026c1de2407fec713cb53
    gst-plugins-base::git+https://gitlab.freedesktop.org/gstreamer/gst-plugins-base.git#commit=2cc319ee13f6b72df3d432b7c75aca81feb260e5
    gst-plugins-good::git+https://gitlab.freedesktop.org/gstreamer/gst-plugins-good.git#commit=e816c6cd73c9e0676828c9e227a049ebad3d019f
    gst-plugins-bad::git+https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad.git#commit=382e373d9be363f1e21b12990a4d12f1ecb6df41
    gst-plugins-ugly::git+https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly.git#commit=ad60e5463f591caa1c8470f180fd0ef8fce4a802
    gst-libav::git+https://gitlab.freedesktop.org/gstreamer/gst-libav.git#commit=67fc1e5c6c5e578dce250ae6310de71a0f5f8ec3
    https://dl.winehq.org/wine/wine-gecko/${_geckover}/wine-gecko-${_geckover}-x86{,_64}.tar.bz2
    https://github.com/madewokherd/wine-mono/releases/download/wine-mono-${_monover}/wine-mono-${_monover}-x86.tar.xz
    proton-unfuck_makefile.patch
    proton-disable_lock.patch
    proton-user_compat_data.patch
    dxvk-extraopts.patch
    vkd3d-extraopts.patch
    patches-remove_leftover_patch.patch
)
noextract=(
    wine-gecko-${_geckover}-{x86,x86_64}.tar.bz2
    wine-mono-${_monover}-x86.tar.xz
)

#-- Compiler and Linker Flags
#CPPFLAGS=""
CFLAGS="-march=x86-64 -mtune=native -O3 -pipe -fcf-protection"
CXXFLAGS="$CFLAGS"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed"
#RUSTFLAGS="-C opt-level=2"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
#DEBUG_RUSTFLAGS="-C debuginfo=2"

prepare() {
    # I know this is fugly and it should NOT be done
    # but the afdko package from AUR breaks regularly.
    # Install it from pip in a virtualenv
    virtualenv --app-data "$srcdir"/afdko/cache --no-wheel afdko
    source afdko/bin/activate
    pip install --no-cache-dir afdko

    [ ! -d gecko ] && mkdir gecko
    mv wine-gecko-${_geckover}-x86{,_64}.tar.bz2 gecko/

    [ ! -d mono ] && mkdir mono
    mv wine-mono-${_monover}-x86.tar.xz mono/

    [ ! -d build ] && mkdir build
    cd proton-ge-custom
    for submodule in ffmpeg openvr OpenXR-SDK fonts/liberation-fonts FAudio vkd3d-proton; do
        git submodule init "${submodule}"
        git config submodule."${submodule}".url "$srcdir"/"${submodule#*/}"
        git submodule update "${submodule}"
    done

    for submodule in wine wine-staging dxvk; do
        git submodule init "${submodule}"
        git config submodule."${submodule}".url "$srcdir"/"${submodule#*/}"
        git submodule update "${submodule}"
    done

    for submodule in gstreamer gst-{plugins-{base,good,bad,ugly},libav,orc}; do
        git submodule init "${submodule}"
        git config submodule."${submodule}".url "$srcdir"/"${submodule#*/}"
        git submodule update "${submodule}"
    done

    pushd vkd3d-proton
    for submodule in subprojects/{dxil-spirv,Vulkan-Headers,SPIRV-Headers}; do
        git submodule init "${submodule}"
        git config submodule."${submodule}".url "$srcdir"/"${submodule#*/}"
        git submodule update "${submodule}"
    done
    pushd subprojects/dxil-spirv
    git submodule init third_party/spirv-headers
    git config submodule.third_party/spirv-headers.url "$srcdir"/SPIRV-Headers
    git submodule update third_party/spirv-headers
    popd
    popd

    for submodule in lsteamclient vrclient_x64 protonfixes; do
        git submodule init "${submodule}"
        git config submodule."${submodule}".url "$srcdir"/"${submodule#*/}-gloriouseggroll"
        git submodule update "${submodule}"
    done

    patch -p1 -i "$srcdir"/patches-remove_leftover_patch.patch
    ./patches/protonprep-nofshack.sh

    patch -p1 -i "$srcdir"/proton-unfuck_makefile.patch
    patch -p1 -i "$srcdir"/proton-disable_lock.patch
    patch -p1 -i "$srcdir"/proton-user_compat_data.patch

    # Export CFLAGS used by upstream if building for redistribution
    # -O2 is adjusted to -O3 since AVX is disabled
#    export CFLAGS="-O3 -march=nocona -mtune=core-avx2"
#    export CXXFLAGS="-O3 -march=nocona -mtune=core-avx2"

    # Uncomment to enable extra optimizations
    # Patch crossfiles with extra optimizations from makepkg.conf
    patch -p1 -i "$srcdir"/dxvk-extraopts.patch
    patch -p1 -i "$srcdir"/vkd3d-extraopts.patch
    local dxvk_cflags="$CFLAGS"
    local dxvk_ldflags="$LDFLAGS"
    # Filter known bad flags before applying optimizations
    # Filter fstack-protector{ ,-all,-strong} flag for MingW.
    # https://github.com/Joshua-Ashton/d9vk/issues/476
    dxvk_cflags="${dxvk_cflags// -fstack-protector*([\-all|\-strong])/}"
    # Doesn't compile with these flags in MingW so remove them.
    # They are also filtered in Wine PKGBUILDs so remove them
    # for winelib versions too.
    dxvk_cflags="${dxvk_cflags/ -fno-plt/}"
    dxvk_ldflags="${dxvk_ldflags/,-z,now/}"
    dxvk_ldflags="${dxvk_ldflags/,-z,relro/}"
    # If using -march=native and the CPU supports AVX, launching a d3d9
    # game can cause an Unhandled exception. The cause seems to be the
    # combination of AVX instructions and tree vectorization (implied by O3),
    # all tested archictures from sandybridge to haswell are affected.
    # Disabling AVX (and AVX2 as a side-effect).
    # Since Wine 5.16 AVX is supported. Testing showed 32bit applications
    # crashing with AVX regardless, but 64bit applications worked just fine.
    # So disable AVX only for the 32bit binaries and AVX2 for the 64bit.
    # AVX2 seems to degrade performance. So disregard the above.
    # Relevant Wine issues
    # https://bugs.winehq.org/show_bug.cgi?id=45289
    # https://bugs.winehq.org/show_bug.cgi?id=43516
    dxvk64_cflags="$dxvk_cflags -mno-avx"
    dxvk32_cflags="$dxvk_cflags -mno-avx"

    sed -i dxvk/build-win64.txt \
        -e "s|@CARGS@|\'${dxvk64_cflags// /\',\'}\'|g" \
        -e "s|@LDARGS@|\'${dxvk_ldflags// /\',\'}\'|g"
    sed -i dxvk/build-win32.txt \
        -e "s|@CARGS@|\'${dxvk32_cflags// /\',\'}\'|g" \
        -e "s|@LDARGS@|\'${dxvk_ldflags// /\',\'}\'|g"
    sed -i vkd3d-proton/build-win64.txt \
        -e "s|@CARGS@|\'${dxvk64_cflags// /\',\'}\'|g" \
        -e "s|@LDARGS@|\'${dxvk_ldflags// /\',\'}\'|g"
    sed -i vkd3d-proton/build-win32.txt \
        -e "s|@CARGS@|\'${dxvk32_cflags// /\',\'}\'|g" \
        -e "s|@LDARGS@|\'${dxvk_ldflags// /\',\'}\'|g"
}

build() {
    cd build
    ../proton-ge-custom/configure.sh \
        --steam-runtime=native \
        --no-steam-runtime \
        --with-ffmpeg \
        --build-name="${pkgname}"

    # Use -mno-avx for wine too
    # https://bugs.winehq.org/show_bug.cgi?id=45289
    # https://bugs.winehq.org/show_bug.cgi?id=43516
    export CFLAGS+=" -mno-avx"
    export CXXFLAGS+=" -mno-avx"
    # From wine-staging PKGBUILD
    # Doesn't compile without remove these flags as of 4.10
    export CFLAGS="${CFLAGS/ -fno-plt/}"
    export CXXFLAGS="${CXXFLAGS/ -fno-plt/}"
    export LDFLAGS="${LDFLAGS/,-z,now/}"
    # MingW Wine builds fail with relro
    export LDFLAGS="${LDFLAGS/,-z,relro/}"

    export WINEESYNC=0
    export WINEFSYNC=0
    export CARGO_HOME="$srcdir/build/cargo"
    SUBMAKE_JOBS="${MAKEFLAGS/-j/}" \
        SYSTEM_GECKO=0 \
        SYSTEM_MONO=0 \
        make -j1 dist
}

package() {
    cd build

    local _compatdir="$pkgdir/usr/share/steam/compatibilitytools.d"
    mkdir -p "$_compatdir"
    cp -rf --no-dereference --preserve=mode,links dist "$_compatdir/${pkgname}"

    mkdir -p "$pkgdir/usr/share/licenses/${pkgname}"
    mv "$_compatdir/${pkgname}"/LICENSE{,.OFL} \
        "$pkgdir/usr/share/licenses/${pkgname}"

    cd "$_compatdir/${pkgname}/dist"
    i686-w64-mingw32-strip --strip-unneeded \
        $(find lib/wine -iname "*.dll" -or -iname "*.exe")
    x86_64-w64-mingw32-strip --strip-unneeded \
        $(find lib64/wine -iname "*.dll" -or -iname "*.exe")

    local _geckodir="share/wine/gecko/wine-gecko-${_geckover}"
    i686-w64-mingw32-strip --strip-unneeded \
        $(find "$_geckodir"-x86 -iname "*.dll" -or -iname "*.exe")
    x86_64-w64-mingw32-strip --strip-unneeded \
        $(find "$_geckodir"-x86_64 -iname "*.dll" -or -iname "*.exe")

    local _monodir="share/wine/mono/wine-mono-${_monover}"
    i686-w64-mingw32-strip --strip-unneeded \
        $(find "$_monodir"/lib/mono -iname "*.dll" -or -iname "*.exe")
    i686-w64-mingw32-strip --strip-unneeded \
        "$_monodir"/lib/x86/*.dll \
        $(find "$_monodir" -iname "*x86.dll" -or -iname "*x86.exe")
    x86_64-w64-mingw32-strip --strip-unneeded \
        "$_monodir"/lib/x86_64/*.dll \
        $(find "$_monodir" -iname "*x86_64.dll" -or -iname "*x86_64.exe")
}

sha256sums=('SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            '06a00cedf391ee07bbca0b3282e5c8ad9d950446d50648d2ff417716816fd1ab'
            'ea5246e4c91d1aa1226658e1749b6e5d0e9353b52b14df79c4b93b6e61a3c59e'
            'b17ac815afbf5eef768c4e8d50800be02af75c8b230d668e239bad99616caa82'
            '1f376915e7c47107ae21479e4f56017a2324558ed22f2a7a9b9dd63c0062a1c1'
            '8263a3ffb7f8e7a5d81bfbffe1843d6f84502d3443fe40f065bcae02b36ba954'
            '20f7cd3e70fad6f48d2f1a26a485906a36acf30903bf0eefbf82a7c400e248f3'
            '23cba1756adc4a76de963414994ffc964047ab1d6f1949fe8133135a91ac0473'
            '7c5f9c20e41c0cd7d0d18867950a776608cef43e0ab9ebad2addb61e613fe17a'
            '28818da77650aa45d655f84900b3fc33f8f4b40a4133b301069a8753a18f3e3b'
)

Yes, I've added the CFLAGS etc. in here even though that's not how you're supposed to do it.

loathingkernel commented on 2021-04-28 20:04 (UTC) (edited on 2021-04-28 20:07 (UTC) by loathingkernel)

This is how submodule update works.

I don't know if -fcf-protection will cause issues. I am still on my previous CFLAGS. Hopefully it won't.

superboringdev commented on 2021-04-28 19:53 (UTC)

Thanks.

From the looks of it, it appears as though the PKGBUILD is cloning the submodules and placing them in the tree manually. Just to be sure, I have pinned as many as I could to what the upstream specifies.

As for the flags, I have removed some of them.

Before:

#CPPFLAGS=""
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS \
        -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"
CXXFLAGS="$CFLAGS"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
#RUSTFLAGS="-C opt-level=2"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
#DEBUG_RUSTFLAGS="-C debuginfo=2"

After:

#-- Compiler and Linker Flags
#CPPFLAGS=""
CFLAGS="-march=x86-64 -mtune=native -O2 -pipe -fcf-protection"
CXXFLAGS="$CFLAGS"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed"
#RUSTFLAGS="-C opt-level=2"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
#DEBUG_RUSTFLAGS="-C debuginfo=2"

I hope this is enough. Back to building and I'll report if it works.

loathingkernel commented on 2021-04-28 19:44 (UTC) (edited on 2021-04-28 19:53 (UTC) by loathingkernel)

The dependencies are already pinned in specific commits as they are specified by upstream. That is how git submodules work. Your issue has to do with the new CFLAGS from arch if you look a bit above in your log. The same issue exists in plain wine. It doesn't like _FORTIFY_SOURCE being redefined. I myself still expecting to see how they will handle such issues in the official wine package to update this.

superboringdev commented on 2021-04-28 19:18 (UTC) (edited on 2021-04-28 19:46 (UTC) by superboringdev)

I can't seem to get anything to build. Official GE instructions (with Vagrant) fail, this one fails, too, even in a chroot:

gcc -m64 -c -o tools/widl/header.o ../../proton-ge-custom/wine/tools/widl/header.c -Itools/widl \
  -I../../proton-ge-custom/wine/tools/widl -Iinclude -I../../proton-ge-custom/wine/include \
  -D__WINESRC__ -Wall -pipe -fcf-protection=none -fno-stack-protector -fno-strict-aliasing \
  -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Winit-self \
  -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \
  -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 \
  -gstrict-dwarf -I/build/proton-ge-custom/src/build/obj-tools64/include -g -march=x86-64 -mtune=generic -O2 -pipe -fexceptions         -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS         -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -mno-avx -mfpmath=sse -fwrapv -fno-strict-aliasing -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
during RTL pass: final
../../proton-ge-custom/wine/dlls/winecrt0/exception.c: In function ‘unwind_frame’:
../../proton-ge-custom/wine/dlls/winecrt0/exception.c:93:1: internal compiler error: in seh_emit_stackalloc, at config/i386/winnt.c:1043
   93 | }
      | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
make[2]: *** [Makefile:255303: dlls/winecrt0/exception.cross.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/build/proton-ge-custom/src/build/obj-wine64'
make[1]: *** [../proton-ge-custom/build/makefile_base.mak:1740: wine64-intermediate] Error 2
make[1]: Leaving directory '/build/proton-ge-custom/src/build'
make: *** [../proton-ge-custom/build/makefile_base.mak:17: nested_make] Error 2

Will attempt to pin the dependencies to specific commits and see if that helps...

EDIT: should be important to say that I'm trying to build 6.4. I did a git hard reset to achieve this.

loathingkernel commented on 2021-04-07 10:43 (UTC) (edited on 2021-04-08 14:38 (UTC) by loathingkernel)

@randomguy343 at least until one of the dependencies of afdko gets updated and afdko stops working again. This comment section is littered with reports of version mismatches between what each of these packages expect and what is actually on the system.

Personally, I used to use a python virtualenv and set the environment before building this and the proton-native package but PKGBUILDs are supposed to take care of any environment prerequisites, hence the current solution.

randomguy343 commented on 2021-04-07 00:01 (UTC) (edited on 2021-04-07 00:02 (UTC) by randomguy343)

@loathingkernel Or you could just install afdko and it's missing dependencies python-fontparts and maybe also python-fontparts beforehand manually.

loathingkernel commented on 2021-04-02 05:39 (UTC) (edited on 2021-04-02 06:22 (UTC) by loathingkernel)

@tessaracht there is no such thing as makeotf package, it is part of afdko and as mentioned in the pinned comment there are issues with the AUR package. That is why it is installed through pip on a virtualenv as mentioned with comments in the PKGBUILD. While the solution has not been a "quick fix" it has been worked around already, check your configuration and if pip was able to install the needed packages.

tessaracht commented on 2021-04-02 02:01 (UTC)

current build fails almost immediately in building fonts, looks like makeotf isn't listed as a build dep:

fontforge -quiet -script ../proton-ge-custom/fonts/scripts/generatefont.pe obj-fonts/LiberationMono-Regular.sfd "CourierNew" "Courier New" "Courier New"
makeotf -f ../proton-ge-custom/fonts/source-han-sans/cidfont.ps.OTC.SC -omitMacNames -ff ../proton-ge-custom/fonts/source-han-sans/features.OTC.SC \
    -fi ../proton-ge-custom/fonts/source-han-sans/cidfontinfo.OTC.SC -mf ../proton-ge-custom/fonts/patches/YaHei-FontMenuNameDB -r -nS -cs 25 -ch ../proton-ge-custom/fonts/source-han-sans/UniSourceHanSansCN-UTF32-H \
    -ci ../proton-ge-custom/fonts/source-han-sans/SourceHanSans_CN_sequences.txt -o ./obj-fonts/SourceHanSansSCRegular.otf
/bin/bash: line 1: makeotf: command not found
make[1]: *** [../proton-ge-custom/build/makefile_base.mak:2048: obj-fonts/SourceHanSansSCRegular.otf] Error 127

should be a quick fix to add it.

randomguy343 commented on 2021-03-19 15:28 (UTC)

@loathingkernel Okay, that worked and the directory was correctly created, thanks and sorry for my comment.

loathingkernel commented on 2021-03-19 15:01 (UTC) (edited on 2021-03-19 15:02 (UTC) by loathingkernel)

@randomguy343 Try rebuilding it without an AUR helper and report back please. I can't make any assumptions or even guesses with the information you have provided thus far.

randomguy343 commented on 2021-03-19 13:26 (UTC)

The installation fails without an error for me, my AUR helper doesn't show the package as installed and the install directory according to the PKGBUILD (/usr/share/steam/compatibilitytools.d) is empty. What am I missing?

loathingkernel commented on 2021-02-20 20:18 (UTC) (edited on 2021-02-20 20:19 (UTC) by loathingkernel)

@class101

  • mingw-w64-tools offers widl which is required to build vkd3d-proton, it is also offered by wine, but mingw-w64-tools is smaller and is the proper tool.
  • lib32-gsm is the x86 counterpart of gsm and is required for equality between the x86 and x86_64 builds of wine.

class101 commented on 2021-02-20 20:07 (UTC) (edited on 2021-02-20 20:10 (UTC) by class101)

Not sure why aur/mingw-w64-tools and aur/lib32-gsm are required. As it compiles fine without them.

I think if possible, it is best to use the less aur packages possible especially with dependencies.

I have the following installed

  • community/mingw-w64-winpthreads
  • community/mingw-w64-headers
  • community/mingw-w64-gcc
  • community/mingw-w64-crt
  • community/mingw-w64-binutils
  • extra/gsm

loathingkernel commented on 2021-02-05 14:42 (UTC) (edited on 2021-02-06 00:05 (UTC) by loathingkernel)

@PedroHLC Great to hear it is working now. Anything else you need, feel free to contact me.

@orlfman So, I downloaded the GOG version and tested it. Works fine here. Unless you can provide some more info, I am afraid I cannot investigate more. I used the current version and launched the game in an env that resembles the env proton sets up. How do you launch the game? What else have you tried?

Edit: On second launch it does get stuck. This gets us somewhere, ok.

Edit2: The game plays the in-game videos fine if you disable the intro videos in the settings. I can't really understand what is going on and why sometimes it plays the intros ok and sometimes it gets stuck.

PedroHLC commented on 2021-02-02 21:21 (UTC)

@loathingkernel whatever it was that bug with memleak, is gone in the current version. Also, thanks for all the support, will schedule it to build automatically...

loathingkernel commented on 2021-02-01 10:43 (UTC) (edited on 2021-02-01 13:12 (UTC) by loathingkernel)

@orlfman Two different issues and I require information of both of them, cause they should not be happening.

For the first one, I decided to use python-virtualenv to install it locally from PyPI with python-pip because there are dependency issues with the afdko package on AUR. But as I just realized I forgot to add python-pip as a dependency, so that is an easy fix.

For the second one, since I cannot test, can you provide any more information that you can think of? It could be linking to the wrong libraries during compilation. Can you point me to a relevant issue in github, a mailing list or something to find the exact component that fails? Local tests with some games have media foundation working, but since there are many possible codecs, your issue might not manifest with the games I play/test. Your cflags look fine to me.

orlfman commented on 2021-02-01 01:09 (UTC) (edited on 2021-02-01 03:24 (UTC) by orlfman)

if anyone else is failing to build due to "makeotf" not found, you need afdko. which is in the aur. and afkdo needs python-pip installed as well. its not pulled in either.

edit: for some odd reason, the compile version doesn't have media foundation working. with the bin version off GE site and the from here in the AUR, media foundation works. but compiling it doesn't. i used the outer worlds to test. could this be caused by cflags? these are my cflags: -march=skylake -O2 -pipe -fno-plt

loathingkernel commented on 2021-01-20 00:38 (UTC)

So, you were correct about the widl dependency. Now mingw-w64-tools is required although wine could satisfy it too.

I still have not figured out the memory leak issue. I am just speculating, but could it be a very high amount of MAKEJOBS (I assume because of the 64gb of memory you mentioned, those machines have a high thread count)?

loathingkernel commented on 2021-01-19 20:55 (UTC) (edited on 2021-01-19 21:00 (UTC) by loathingkernel)

OK, I just rebuilt it to test the upstream opts, and it was fine. I am rebuilding it now to keep a log to compare. Will report back afterwards.

PedroHLC commented on 2021-01-19 20:39 (UTC) (edited on 2021-01-19 20:40 (UTC) by PedroHLC)

They changed vkd3d to be built by mingw to produce a dll similar to dxvk.

It required it, but looking at the logs, seems like it wasn't used.

but what do you mean by struggling without memory?

It grows in memory usage until the kernels kill it... (Really, for half a minute I see my memory usage grow up to 64Gb)

similar to building on a tmpfs

Yep, that what I thought at first, then I tried building in the disk, and the result was the same. It's a mingw process, and it's kept in "D" state after failing (and there it stays until I hard halt the machine):

build-user  367354  0.0  0.0  69708 13232 ?        D    15:27   0:00 /usr/lib/gcc/x86_64-w64-mingw32/10.2.0/cc1 -quiet -I dlls/d3dx9_43 -I ../../proton-ge-custom/wine/dlls/d3dx9_43 -I ../../proton-ge-custom/wine/dlls/d3dx9_36 -I include -I ../../proton-ge-custom/wine/include -I ../../proton-ge-custom/wine/include/msvcrt -D_REENTRANT -D __WINESRC__ -D D3DX_SDK_VERSION=43 -D _UCRT -D WINE_CROSS_PE -D _FORTIFY_SOURCE=2 ../../proton-ge-custom/wine/dlls/d3dx9_36/skin.c -quiet -dumpbase skin.c -mcx16 -march=nocona -mtune=core-avx2 -mno-avx -mfpmath=sse -auxbase-strip dlls/d3dx9_43/skin.cross.o -gdwarf-2 -gstrict-dwarf -g -O2 -Wall -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -Wabsolute-value -Wformat=0 -Wformat-overflow=1 -Wnonnull -fwrapv -fno-strict-aliasing -o /tmp/ccYgILfS.s

(I've been building a bunch of packages for the last 2yrs, and never seen this before)

loathingkernel commented on 2021-01-19 20:24 (UTC) (edited on 2021-01-19 20:28 (UTC) by loathingkernel)

It's missing widl (executable) to build vkd3d;

It shouldn't be needing it at all. They changed vkd3d to be built by mingw to produce a dll similar to dxvk. Or it should be using the one from the included wine. Does it complain about it? If so there should be an issue somewhere.

There is a process leaking memory

I have no encountered that, but what do you mean by struggling without memory? As far as I understand this seems to me similar to building on a tmpfs without enough allocated space, but also different enough from it to not be sure about it at all.

PedroHLC commented on 2021-01-19 19:31 (UTC)

It's missing widl (executable) to build vkd3d;

There is a process leaking memory while compiling wine/dlls/d3dx9_36/skin.c, no clue why, but it generates a valid object before struggling without memory... The worst part is Linux trying to "core dump" a process as large as your memory. (This happened in two different chaotic's clusters)

PedroHLC commented on 2021-01-18 18:46 (UTC)

Ok, thanks @loathingkernel, I'll unset CXX/CFLAGS just in proton-ge-custom builds...

loathingkernel commented on 2021-01-18 18:26 (UTC) (edited on 2021-01-19 17:06 (UTC) by loathingkernel)

@PedroHLC, I am referring to proton's upstream. In this package (as well as proton-native) I am patching the makefile with the following

-OPTIMIZE_FLAGS := -O2 -march=nocona $(call cc-option,$(CC),-mtune=core-avx2,) -mfpmath=sse
+CFLAGS ?= -O2 -march=nocona $(call cc-option,$(CC),-mtune=core-avx2,)
+OPTIMIZE_FLAGS := $(CFLAGS) -mfpmath=sse

Upstream proton uses -march=nocona with optional -mtune=core-avx2. My patch changes that and takes the CFLAGS from makepkg. But that might not be what we want if -march=x86_64 is specified in makepkg.conf because it is lesser than nocona. I would suggest to either unset CFLGAGS and CXXFLAGS to use the defaults (not sure it will pass it to all sub-makes properly), or use a proton specific makepkg.conf with -O2 -march=nocona -mtune=core-avx2 as CFLAGS/CXXFLAGS

Edit: I was wrong, unsetting them won't work, because they will be set again later for -mno-avx (I don't want to use conditionals in the PKGBUILD to accommodate for unset CXX/CFLAGS), it is better to hard-code them as above if you want to go that route.

PedroHLC commented on 2021-01-18 18:05 (UTC)

Yeah, I've updated the makepkg.conf, actually changed the file-overwrite behaviour with an file-append of just what I need to change. So the CFLAGS shall be kept with currents upstream's makepkg.conf.

loathingkernel commented on 2021-01-18 18:02 (UTC)

@PedroHLC, correct me if I am mistaken, but you are building proton packages for redistribution through the chaotic-aur, correct? If so, I think we should find a way to build it with the proper CFLAGS from upstream, otherwise these packages might be under-performing if built targeting base x86_64.

PedroHLC commented on 2021-01-18 17:00 (UTC)

@loathingkernel, yeah you're right, was using an outdated makepkg.conf

PS: We got a stable 6.0 release now: https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/6.0-GE-1

loathingkernel commented on 2021-01-17 20:03 (UTC) (edited on 2021-01-17 20:03 (UTC) by loathingkernel)

Those flags is filtered for dxvk and vkd3d already, even if one was set, they wouldn't fail. Can you verify that any of those are not set for you chroot by mistake or omission?

PedroHLC commented on 2021-01-17 19:57 (UTC)

Clean chroot each build, so it shouldn't... And that's happening in winedbg functions not dxvk or vkd3d.

loathingkernel commented on 2021-01-17 19:54 (UTC) (edited on 2021-01-17 19:56 (UTC) by loathingkernel)

@PedroHLC, it shouldn't be broken, no. Are you building with -fstack-protector?

PedroHLC commented on 2021-01-17 19:16 (UTC) (edited on 2021-01-17 19:17 (UTC) by PedroHLC)

Is this broken with current mingw-w64? I tried building this and bumping to current git and both fail with a bunch of undefined reference to '__stack_chk_guard' and __stack_chk_fail. There is nothing in arch's bugzilla...

loathingkernel commented on 2020-12-08 10:13 (UTC) (edited on 2020-12-08 10:14 (UTC) by loathingkernel)

@juxuanu Thanks for the log. Well, as far as I can see, courier.ttf the build requires at that point is part of wine, and provided with the source, so I can't imagine what might be going on. It builds fine here, although I am not building in a chroot due to space constraints. If you are building on tmpfs, could it be that tmpfs fails silently due to not enough space? I really don't know yet, I am sorry.

juxuanu commented on 2020-12-08 08:46 (UTC)

Here it is, @loathingkernel. https://mega.nz/file/nJ0THSzL#YttG886Cz2pUQCNAoOnrugf3coyCmTaoF23TeZHaxDY

loathingkernel commented on 2020-12-07 21:02 (UTC)

@juxuanu what leads up to that error? An error like that alone is not informative.

juxuanu commented on 2020-12-07 16:08 (UTC) (edited on 2020-12-07 16:08 (UTC) by juxuanu)

Fails to build in clean chroot:

Error: Cannot open face ../../proton-ge-custom/wine/fonts/courier.ttf

Any suggestions?

Dennis commented on 2020-11-22 09:19 (UTC)

@loathingkernel: Yep, ty, noticed the outdated mingw-w64 packages right after posting my previous comment (see edits). So yeah, after updating those, the build succeeded.

loathingkernel commented on 2020-11-22 08:58 (UTC) (edited on 2020-11-22 09:06 (UTC) by loathingkernel)

@J-StrY Not an issue with this package, read the pinned comment please.

@Dennis I have only tested with Mingw-w64 10 which has been out since Oct 23, your system is at mingw-w64 8.2 so I am going to label it a misconfiguration or lack of updates on your side of things for now.

Dennis commented on 2020-11-22 08:38 (UTC) (edited on 2020-11-22 09:17 (UTC) by Dennis)

EDIT2: Ok yes, with the mingw-w64- packages from the official repo, the package build process finished successfully.

EDIT: Nevermind... I had pretty old mingw-w64- packages, will update those and try building again.

I am getting these build errors before it stops trying to finish makepkg.

FAILED: src/util/libutil.a.p/log_log.cpp.obj i686-w64-mingw32-g++ -Isrc/util/libutil.a.p -Isrc/util -I../../proton-ge-custom/dxvk/src/util -I../../proton-ge-custom/dxvk/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O3 -DNOMINMAX -msse -msse2 -march=x86-64 -mtune=generic -O2 -mno-avx -MD -MQ src/util/libutil.a.p/log_log.cpp.obj -MF src/util/libutil.a.p/log_log.cpp.obj.d -o src/util/libutil.a.p/log_log.cpp.obj -c ../../proton-ge-custom/dxvk/src/util/log/log.cpp ../../proton-ge-custom/dxvk/src/util/log/log.cpp: In constructor ‘dxvk::Logger::Logger(const string&)’: ../../proton-ge-custom/dxvk/src/util/log/log.cpp:13:69: error: no matching function for call to ‘std::basic_ofstream<char>::basic_ofstream(const wchar_t*)’ m_fileStream = std::ofstream(str::tows(path.c_str()).c_str());

/usr/i686-w64-mingw32/include/c++/8.2.0/fstream:771:32: error: request for member ‘make_preferred’ in ‘std::declval<const wchar_t*&>()’, which is of non-class type ‘const wchar_t*’ template<typename _Path, typename _Require = _If_fs_path<_Path>>

FAILED: src/util/libutil.a.p/config_config.cpp.obj i686-w64-mingw32-g++ -Isrc/util/libutil.a.p -Isrc/util -I../../proton-ge-custom/dxvk/src/util -I../../proton-ge-custom/dxvk/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O3 -DNOMINMAX -msse -msse2 -march=x86-64 -mtune=generic -O2 -mno-avx -MD -MQ src/util/libutil.a.p/config_config.cpp.obj -MF src/util/libutil.a.p/config_config.cpp.obj.d -o src/util/libutil.a.p/config_config.cpp.obj -c ../../proton-ge-custom/dxvk/src/util/config/config.cpp ../../proton-ge-custom/dxvk/src/util/config/config.cpp: In static member function ‘static dxvk::Config dxvk::Config::getUserConfig()’: ../../proton-ge-custom/dxvk/src/util/config/config.cpp:616:61: error: no matching function for call to ‘std::basic_ifstream<char>::basic_ifstream(const wchar_t*)’ std::ifstream stream(str::tows(filePath.c_str()).c_str());

/usr/i686-w64-mingw32/include/c++/8.2.0/fstream:545:32: error: request for member ‘make_preferred’ in ‘std::declval<const wchar_t*&>()’, which is of non-class type ‘const wchar_t*’ template<typename _Path, typename _Require = _If_fs_path<_Path>>

ninja: build stopped: subcommand failed. make[1]: [../proton-ge-custom/build/makefile_base.mak:1805: dxvk32] Error 1 make[1]: Leaving directory '/mnt/RAM/proton-ge-custom/src/build' make: [../proton-ge-custom/build/makefile_base.mak:17: nested_make] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

J-StrY commented on 2020-11-22 08:33 (UTC) (edited on 2020-11-22 09:54 (UTC) by J-StrY)

EDIT2: NVM had a typo in my config flags

EDIT: As @loathingkernel pointed out this is not issue with the package. I'm now getting:

libmp3lame.so: error adding symbols: file in wrong format

Guessing this is probably because of my CFLAGS as pointed above - will try changing it.

python-fontparts was required dependency on my build.

loathingkernel commented on 2020-11-21 10:28 (UTC) (edited on 2022-06-15 14:13 (UTC) by loathingkernel)

Notes about this package

  • If you encounter issues while using this package, please contact me here first before reporting an issue to the upstream repository. Don't post logs, link to them. If you are using Manjaro, another derivative or an AUR helper, please mention it, I DO NOT TEST AGAINST THEM AND I CANNOT KNOW WHAT MIGHT BE WRONG WITH THE DISTRO/HELPER OF YOUR CHOICE.

  • It takes a LOT of time and space to build. Building with multiple jobs helps but might cause builds to fail in rare cases. Be sure to have at least 16GB of RAM if you are building on tmpfs

  • It is NOT built against Steam Linux Runtime (Sniper, Soldier, etc) and as such it doesn't require it. Still, is detected by Steam and works properly (preferable through steam-native).

  • This PKGBUILD uses CFLAGS, CXXFLAGS and LDFLAGS hardcoded in the PKGBUILD itself. By default it uses the same C[XX]FLAGS as upstream, namely -march=nocona and -mtune=core-avx2. To change them you will have to edit the PKGBUILD itself. Due to the nature of this package some flags can cause it to fail to build or not function properly. I try to filter them out but it is based on testing. If you have a feeling that compile-time options are involved in the issues you are having please include them in your comment. Currently the filtered options are -fstack-protector-{,-strong,-all}(dxvk and vkd3d only), -fno-plt, -z,relro, -z,now. Also the use of AVX instructions is disabled through -mno-avx.

  • If you are not using CFLAGS and CXXFLAGS specific to your system this package won't offer much in terms of performance as the upstream build flags already target the nocona (Core2) architecture. It will possibly perform worse than upstream. The only benefits you get is not depending on steam linux runtime as well as linking to Arch libraries. If you still want to build it, you can uncomment the relevant lines in the PKGBUILD to enable CFLAGS and CXXFLAGS similar to the upstream.

  • There have been reports with afdko failing to find its dependencies during building. I can't do anything about that as I don't maintain that package. It is NOT an issue with this package and I haven't found a way to not depend on it. Please don't report fails due to afdko (or any of its python- dependencies, they are pulled in due to afdko and only used by that), it has been discussed enough. There are possible workarounds in the comments.

  • It contains a patch to store game prefixes in the main Steam Library under $HOME/.local/share/Steam/steamapps/compatdata. It helps with isolation of game prefixes between users and works around issues with shared libraries on NTFS partitions due to drive symlinks. To enable it, set the PROTON_USER_COMPAT_DATA env variable to 1.

  • This package requires a Rust 32 bit target, please run rustup target install i686-unknown-linux-gnu BEFORE posting any issues if you're using rustup.

gyscos commented on 2020-11-20 18:34 (UTC)

Aah - I did have lib32-rust-libs, but I guess maybe the rustc toolchain installed by rustup just ignores it and required me to install it separately? :shrug:

Anywoo, 1:5.21.GE.1-2 now installed properly, thanks so much for the support! :)

loathingkernel commented on 2020-11-20 08:54 (UTC) (edited on 2020-11-20 09:19 (UTC) by loathingkernel)

@gyscos I am not well versed in rust but when I encountered a similar issue, installing lib32-rust-libs solved it for me. It is included in the dependencies. Could this be some configuration on your side?

Edit: Since you are using rustup, that seems to be the cause, as your rust installation is not managed by pacman.

gyscos commented on 2020-11-20 04:06 (UTC)

Ah seems like it needs the i686-unknown-linux-gnu target for rust as well; though I'm not sure how to specify this in a PKGBUILD? I had to run:

rustup target add i686-unknown-linux-gnu

loathingkernel commented on 2020-11-19 21:39 (UTC)

@gyscos makes sense, since it seems like vkd3d has to be explicitly disabled in wine configure. I am going to push a new release of the package that disables it.

loathingkernel commented on 2020-11-19 20:43 (UTC) (edited on 2020-11-19 21:03 (UTC) by loathingkernel)

@randyzhu No it should not, definitely should not. I have thought about it but GE's git habits are messy to say least, and it makes it almost impossible to follow different branches. Releases are tagged before the final version, sometimes at the start of the release but not always, branches are getting merged and reused for different things, branches that per their title do the same thing, and changes from upstream proton are merged by hand rather than rebasing or cherry-picking. All this make it really hard to follow what commit/branch each release refers to. That is why this package always follows the latest release by date of release rather than version number or branch.

gyscos commented on 2020-11-19 20:38 (UTC) (edited on 2020-11-19 20:58 (UTC) by gyscos)

Well, without any vkd3d installed (is that what you wanted me to try?), I get unsurprisingly:

../../proton-ge-custom/wine/dlls/d3d12/d3d12_main.c:39:10: fatal error: vkd3d.h: No such file or directory
   39 | #include <vkd3d.h>
      |          ^~~~~~~~~

Full log: https://gist.github.com/e167b24d6a3ff8984d1556c331b3cf5e

Now trying after installing community/vkd3d=1.2. At least its /usr/include/vkd3d/vkd3d_shader.h file does seem to include the proper type definitions...

randyzhu commented on 2020-11-19 20:22 (UTC)

Is this package based on stable releases or pre-releases? If it's based on the stable version, this package should be renamed to proton-ge-custom-stable, and another pre-release package should be called proton-ge-custom.

loathingkernel commented on 2020-11-19 20:04 (UTC) (edited on 2020-11-19 20:07 (UTC) by loathingkernel)

Actually no, you are onto something. Since the last proton update vkd3d is compiled separately as a Windows dll rather than built-in in wine, hence proton's vkd3d is not available prior to building wine and the system one is used. If you try again, can you temporarily remove vkd3d altogether before building and see if it happens? If it works, I will disable wine's vkd3d to accommodate such potential issues as proton doesn't need it anyway.

gyscos commented on 2020-11-19 19:42 (UTC) (edited on 2020-11-19 19:44 (UTC) by gyscos)

The full log is pretty big (much larger than my terminal history), will need to re-build to get it.

In the meantime I think it might be because I have aur/vkd3d-valve=1.1-2 rather than community/vkd3d=1.2? Seems to be where PFN_vkd3d_shader_compile is defined.

EDIT: nevermind, I guess it uses the include from the vkd3d-proton submodule and just ignores my system one.

loathingkernel commented on 2020-11-19 19:15 (UTC) (edited on 2020-11-19 19:17 (UTC) by loathingkernel)

Could you post the complete log somewhere? This is not happening here. A dependency might be missing or it could be something else, I can't know without the complete log.

gyscos commented on 2020-11-19 19:00 (UTC)

Getting some errors building this package (many build errors, here are the first few ones):

../../proton-ge-custom/wine/dlls/wined3d/shader_spirv.c:34:8: error: unknown type name ‘PFN_vkd3d_shader_compile’
   34 | static PFN_vkd3d_shader_compile vkd3d_shader_compile;
      |        ^~~~~~~~~~~~~~~~~~~~~~~~
../../proton-ge-custom/wine/dlls/wined3d/shader_spirv.c:35:8: error: unknown type name ‘PFN_vkd3d_shader_free_messages’
   35 | static PFN_vkd3d_shader_free_messages vkd3d_shader_free_messages;
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../proton-ge-custom/wine/dlls/wined3d/shader_spirv.c:36:8: error: unknown type name ‘PFN_vkd3d_shader_free_scan_descriptor_info’
   36 | static PFN_vkd3d_shader_free_scan_descriptor_info vkd3d_shader_free_scan_descriptor_info;
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../proton-ge-custom/wine/dlls/wined3d/shader_spirv.c:38:8: error: unknown type name ‘PFN_vkd3d_shader_get_version’
   38 | static PFN_vkd3d_shader_get_version vkd3d_shader_get_version;
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

PedroHLC commented on 2020-11-01 18:40 (UTC)

@loathingkernel it fails to build in a clean chroot without it, so you just need to add it to makedepends...

In file included from .././syn-vrclient32/vrclient/vrclient_main.c:19:
.././syn-vrclient32/vrclient/dxvk-interop.h:39:10: fatal error: vulkan/vulkan.h: No such file or directory
   39 | #include <vulkan/vulkan.h>
      |          ^~~~~~~~~~~~~~~~~
compilation terminated.

loathingkernel commented on 2020-11-01 18:12 (UTC)

@rustemb care to elaborate on that? Is it failing to build? And with what error?

rustemb commented on 2020-11-01 17:57 (UTC)

missing vulkan-headers

loathingkernel commented on 2020-10-20 16:20 (UTC) (edited on 2020-10-20 16:20 (UTC) by loathingkernel)

@Dude803 It doesn't matter, the wine-mono version required by each wine version is hard-coded, that is why it is included and not linked to the system wine-mono.

Dude803 commented on 2020-10-20 15:48 (UTC)

There is a new version of wine-mono

loathingkernel commented on 2020-09-29 07:39 (UTC) (edited on 2020-09-29 07:40 (UTC) by loathingkernel)

@gyscos Nope, find what package requires python-tqdm and report it there. Building this one doesn't directly depend on it.

gyscos commented on 2020-09-29 00:18 (UTC)

Seems like I had to install python-tqdm to be able to build, should it be added to the make-depends?

loathingkernel commented on 2020-08-08 07:48 (UTC) (edited on 2020-08-08 07:49 (UTC) by loathingkernel)

It is not a new version per se, it is a different stable branch which is also based on a previous wine version, namely 5.9, something that will require manual intervention to upgrade.

Your issue is not with this package but python-fontparts, that is what is missing the mangled dependencies, as it is explicitly stated in the log you posted.

These two things combined make me think that updating this package to a previous version will cause more confusion and the stable branch should be a different package.

MrWhiskers commented on 2020-08-08 00:04 (UTC) (edited on 2020-08-08 00:05 (UTC) by MrWhiskers)

Seems out of date again (new version released 11 days ago).

Also the current version doesn't seem to resolve for me:

==> Making package: python-fontparts 0.9.2-1 (Fri 07 Aug 2020 08:00:05 PM EDT)
==> Checking runtime dependencies...
==> Missing dependencies:
  -> python-booleanoperations
==> Checking buildtime dependencies...
==> Missing dependencies:
  -> python-fontpens
==> ERROR: Could not resolve all dependencies.

and I cannot install those individually, they seem to have dependencies on one another?

loathingkernel commented on 2020-06-26 08:59 (UTC) (edited on 2020-06-26 08:59 (UTC) by loathingkernel)

@SolarAquarion I am aware of it, rebasing the makfile and testing take time though which I don't have presently due to exams. Maybe I will find some in the near future.

SolarAquarion commented on 2020-06-25 19:46 (UTC)

there has been a updated version

atxnor commented on 2020-06-17 08:57 (UTC)

@Plexcon before build this pkg use this: yay -i mingw-w64-gcc-bin

loathingkernel commented on 2020-06-08 18:15 (UTC)

@Samega7Cattac: depends on the package. Look at the configuration step (right before make usually) on how to specify options. In this case it was done by specifying -Daom=disabled in meson arguments. It differs between build systems. Or remove lib32-aom package from your system.

Samega7Cattac commented on 2020-06-08 17:57 (UTC) (edited on 2020-06-08 18:14 (UTC) by Samega7Cattac)

@loathingkernel yes. Seems this is not the only package I'm having issues with lib32-aom (already tried to rebuild). How to disable the linking?

loathingkernel commented on 2020-06-08 12:52 (UTC) (edited on 2020-06-08 12:52 (UTC) by loathingkernel)

@Samega7Cattac: Do you have lib32-aom installed? Disabled linking to it for the time being. Test again.

Samega7Cattac commented on 2020-06-07 16:09 (UTC)

[441/545] Linking target ext/aom/libgstaom.so
FAILED: ext/aom/libgstaom.so 
gcc  -o ext/aom/libgstaom.so 'ext/aom/577fce2@@gstaom@sha/gstaom.c.o' 'ext/aom/577fce2@@gstaom@sha/gstav1enc.c.o' 'ext/aom/577fce2@@gstaom@sha/gstav1dec.c.o' 'ext/aom/577fce2@@gstaom@sha/gstav1utils.c.o' -flto -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group -Wl,-soname,libgstaom.so -Wl,-Bsymbolic-functions -m32 -march=native -O2 -pipe -mno-avx -mfpmath=sse -fwrapv -fno-strict-aliasing -Wl,-O1,--sort-common,--as-needed,-z,relro /run/media/samega7cattac/Data/gits/proton-ge-custom/src/build/obj-tools32/lib/libgstpbutils-1.0.so /run/media/samega7cattac/Data/gits/proton-ge-custom/src/build/obj-tools32/lib/libgstaudio-1.0.so /run/media/samega7cattac/Data/gits/proton-ge-custom/src/build/obj-tools32/lib/libgstvideo-1.0.so /run/media/samega7cattac/Data/gits/proton-ge-custom/src/build/obj-tools32/lib/libgstbase-1.0.so /run/media/samega7cattac/Data/gits/proton-ge-custom/src/build/obj-tools32/lib/libgstreamer-1.0.so /run/media/samega7cattac/Data/gits/proton-ge-custom/src/build/obj-tools32/lib/libgobject-2.0.so /run/media/samega7cattac/Data/gits/proton-ge-custom/src/build/obj-tools32/lib/libglib-2.0.so /usr/lib32/libaom.so -Wl,--end-group
/usr/bin/ld: /tmp/libgstaom.so.QMVOHw.ltrans0.ltrans.o: in function `.L75':
<artificial>:(.text+0xf39): undefined reference to `aom_codec_control'
/usr/bin/ld: /tmp/libgstaom.so.QMVOHw.ltrans0.ltrans.o: in function `gst_av1_enc_set_format':
<artificial>:(.text+0x1ee7): undefined reference to `aom_codec_control'
collect2: error: ld returned 1 exit status
[446/545] Compiling C object 'ext/dash/0b60ed1@@gstdashdemux@sha/gstdashdemux.c.o'
ninja: build stopped: subcommand failed.
make[1]: *** [../proton-ge-custom/build/makefile_base.mak:1134: gst_bad32] Error 1
make[1]: Leaving directory '/run/media/samega7cattac/Data/gits/proton-ge-custom/src/build'
make: *** [../proton-ge-custom/build/makefile_base.mak:17: nested_make] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

loathingkernel commented on 2020-05-28 22:42 (UTC) (edited on 2020-05-28 23:10 (UTC) by loathingkernel)

@Plexcon Not an issue with this pkgbuild.

Plexcon commented on 2020-05-28 20:43 (UTC) (edited on 2020-05-28 20:53 (UTC) by Plexcon)

==> Checking dependencies while compiling... ==> Missing dependencies: -> mingw-w64-gcc-base ==> ERROR: Not all dependencies could be solved.

curl: (35) OpenSSL SSL_connect: Connection reset by remote machine in connection to iweb.dl.sourceforge.net:443 ==> ERROR: There were failures during the download from https://sourceforge.net/projects/mingw-w64-builds/files/mingw-w64-gcc/mingw-w64-gcc-10.1.0.tar.xz Canceling... Error downloading sources: mingw-w64-gcc-bin

Ota-Coder commented on 2020-05-08 21:31 (UTC)

Oh you're right @loathingkernel. My apologies. Will try again :)

loathingkernel commented on 2020-05-08 20:51 (UTC)

@Ota-Coder Are you sure this is the correct package to report this? This PKGBUILD doesn't have a check function. A dependency of this packages is failing to build. Probably python-defcon judging by the log, which is a dependency of afdko which in turn is required to build this package.

Ota-Coder commented on 2020-05-08 20:23 (UTC)

Hi! I'm currently facing this error:

=========================== short test summary info ============================
FAILED Lib/defcon/test/objects/test_validation.py::UFOReadWriteValidateTest::test_customClasses
================== 1 failed, 374 passed, 13 warnings in 4.80s ==================
==> ERROR: A failure occurred in check().
    Aborting...

Did I miss installing something?

loathingkernel commented on 2020-03-25 19:27 (UTC) (edited on 2020-03-25 19:27 (UTC) by loathingkernel)

@GrandGamer This is most likely due to an issue on your end. Possibly related to MinGW. I am interested to see why this might be happening if you manage to debug it.

GrandGamer commented on 2020-03-25 16:32 (UTC)

Nope, same error at the same spot. I think I will try the prebuilt binary instead as per your suggestion.

loathingkernel commented on 2020-03-25 15:52 (UTC) (edited on 2020-03-25 16:39 (UTC) by loathingkernel)

@GrandGamer I assumed that because of pamac in the path and the -fstack-protector-strong in CFLAGS, both of which are defaults for Manjaro, but I could be wrong.

I am trying to reproduce it here and I can't. I would suggest rebuilding the mingw-w64-gcc package through makepkg before trying again, in case something went wrong there.

In any case, since you are using very conservative CFLAGS, and probably an unmodified mingw-w64-gcc package with sjlj-exceptions enabled you won't gain much from building from source rather than using the binary release of proton-ge-custom either from AUR or directly from Github. It will most likely hurt your performance all things considered.

If you want to build it though, I just updated the PKGBUILD, if you don't mind to try it again.

GrandGamer commented on 2020-03-25 12:10 (UTC)

I did build mingw through pamac yes. I also tried building the whole package through yay and had the same issue. dxvk32 appears to be building just fine but when it tries to build the 64 one it produces this error.

GrandGamer commented on 2020-03-25 11:38 (UTC)

I'm not on Manjaro but here it is. Not sure if there is a better way to post it.

#!/hint/bash
#
# /etc/makepkg.conf
#

MAKEFLAGS="-j$(nproc)"

#########################################################################
# SOURCE ACQUISITION
#########################################################################
#
#-- The download utilities that makepkg should use to acquire sources
#  Format: 'protocol::agent'
# DLAGENTS=('file::/usr/bin/curl -gqC - -o %o %u'
#           'ftp::/usr/bin/curl -gqfC - --ftp-pasv --retry 3 --retry-delay 3 -o %o %u'
#           'http::/usr/bin/curl -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
#           'https::/usr/bin/curl -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
#           'rsync::/usr/bin/rsync --no-motd -z %u %o'
#           'scp::/usr/bin/scp -C %u %o')

DLAGENTS=('ftp::/usr/bin/aria2c -UWget -s4 %u -o %o'
          'http::/usr/bin/aria2c -UWget -s4 %u -o %o'
          'https::/usr/bin/aria2c -UWget -s4 %u -o %o'
          'rsync::/usr/bin/rsync --no-motd -z %u %o'
          'scp::/usr/bin/scp -C %u %o')

# Other common tools:
# /usr/bin/snarf
# /usr/bin/lftpget -c
# /usr/bin/wget

#-- The package required by makepkg to download VCS sources
#  Format: 'protocol::package'
VCSCLIENTS=('bzr::bzr'
            'git::git'
            'hg::mercurial'
            'svn::subversion')

#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

#########################################################################
# BUILD ENVIRONMENT
#########################################################################
#
# Defaults: BUILDENV=(!distcc !color !ccache check !sign)
#  A negated environment option will do the opposite of the comments below.
#
#-- distcc:   Use the Distributed C/C++/ObjC compiler
#-- color:    Colorize output messages
#-- ccache:   Use ccache to cache compilation
#-- check:    Run the check() function if present in the PKGBUILD
#-- sign:     Generate PGP signature file
#
BUILDENV=(!distcc color !ccache check !sign)
#
#-- If using DistCC, your MAKEFLAGS will also need modification. In addition,
#-- specify a space-delimited list of hosts running in the DistCC cluster.
#DISTCC_HOSTS=""
#
#-- Specify a directory for package building.
#BUILDDIR=/tmp/makepkg

#########################################################################
# GLOBAL PACKAGE OPTIONS
#   These are default values for the options=() settings
#########################################################################
#
# Default: OPTIONS=(!strip docs libtool staticlibs emptydirs !zipman !purge !debug)
#  A negated option will do the opposite of the comments below.
#
#-- strip:      Strip symbols from binaries/libraries
#-- docs:       Save doc directories specified by DOC_DIRS
#-- libtool:    Leave libtool (.la) files in packages
#-- staticlibs: Leave static library (.a) files in packages
#-- emptydirs:  Leave empty directories in packages
#-- zipman:     Compress manual (man and info) pages in MAN_DIRS with gzip
#-- purge:      Remove files specified by PURGE_TARGETS
#-- debug:      Add debugging flags as specified in DEBUG_* variables
#
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug)

#-- File integrity checks to use. Valid: md5, sha1, sha256, sha384, sha512
INTEGRITY_CHECK=(md5)
#-- Options to be used when stripping binaries. See `man strip' for details.
STRIP_BINARIES="--strip-all"
#-- Options to be used when stripping shared libraries. See `man strip' for details.
STRIP_SHARED="--strip-unneeded"
#-- Options to be used when stripping static libraries. See `man strip' for details.
STRIP_STATIC="--strip-debug"
#-- Manual (man and info) directories to compress (if zipman is specified)
MAN_DIRS=({usr{,/local}{,/share},opt/*}/{man,info})
#-- Doc directories to remove (if !docs is specified)
DOC_DIRS=(usr/{,local/}{,share/}{doc,gtk-doc} opt/*/{doc,gtk-doc})
#-- Files to be removed from all packages (if purge is specified)
PURGE_TARGETS=(usr/{,share}/info/dir .packlist *.pod)
#-- Directory to store source code in for debug packages
DBGSRCDIR="/usr/src/debug"

#########################################################################
# PACKAGE OUTPUT
#########################################################################
#
# Default: put built package and cached source in build directory
#
#-- Destination: specify a fixed directory where all packages will be placed
#PKGDEST=/home/packages
#-- Source cache: specify a fixed directory where source files will be cached
#SRCDEST=/home/sources
#-- Source packages: specify a fixed directory where all src packages will be placed
#SRCPKGDEST=/home/srcpackages
#-- Log files: specify a fixed directory where all log files will be placed
#LOGDEST=/home/makepkglogs
#-- Packager: name/email of the person or organization building packages
#PACKAGER="John Doe <john@doe.com>"
#-- Specify a key to use for package signing
#GPGKEY=""

#########################################################################
# COMPRESSION DEFAULTS
#########################################################################
#
COMPRESSGZ=(gzip -c -f -n)
COMPRESSBZ2=(bzip2 -c -f)
COMPRESSXZ=(xz -c -z -)
COMPRESSLRZ=(lrzip -q)
COMPRESSLZO=(lzop -q)
COMPRESSZ=(compress -c -f)

#########################################################################
# EXTENSION DEFAULTS
#########################################################################
#
# WARNING: Do NOT modify these variables unless you know what you are
#          doing.
#
PKGEXT='.pkg.tar.xz'
SRCEXT='.src.tar.gz'

loathingkernel commented on 2020-03-25 11:35 (UTC) (edited on 2020-03-25 11:36 (UTC) by loathingkernel)

@GrandGamer This seems highly manjaro specific, can you post your makepkg.conf as I don't have access to a manjaro system? Also, did you build mingw through pamac or did you use makepkg? In other words, is your mingw working, for example, have you compiled one of the dxvk packages on its own with it?

GrandGamer commented on 2020-03-25 10:53 (UTC)

I'm getting the following Meson build error when it's trying to build dxvk64:

The Meson build system
Version: 0.53.2
Source dir: /tmp/pamac-build/proton-ge-custom/src/proton-ge-custom/dxvk
Build dir: /tmp/pamac-build/proton-ge-custom/src/build/obj-dxvk64
Build type: cross build
Project name: dxvk
Project version: v1.6
Appending CFLAGS from environment: '-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -mno-avx'
Appending LDFLAGS from environment: ['-Wl,-O1,--sort-common,--as-needed,-z,relro']
Appending CPPFLAGS from environment: '-D_FORTIFY_SOURCE=2'
C compiler for the build machine: gcc (gcc 9.3.0 "gcc (Arch Linux 9.3.0-1) 9.3.0")
C linker for the build machine: gcc ld.bfd 2.34
Appending CXXFLAGS from environment: '-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt'
Appending LDFLAGS from environment: ['-Wl,-O1,--sort-common,--as-needed,-z,relro']
Appending CPPFLAGS from environment: '-D_FORTIFY_SOURCE=2'
C++ compiler for the build machine: g++ (gcc 9.3.0 "g++ (Arch Linux 9.3.0-1) 9.3.0")
C++ linker for the build machine: g++ ld.bfd 2.34

meson.build:1:0: ERROR: Unable to determine dynamic linker