Arch Linux User Repository

Notes about this package

• 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

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

• This PKGBUILD uses CFLAGS, CXXFLAGS and LDFLAGS from makepkg.conf. 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.

• 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 symlinks. To enable it, set the PROTON_USER_COMPAT_DATA env variable to 1.

• It is NOT built against steam linux runtime and as such it doesn't require it.

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

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

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

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

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

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

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

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

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.

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)

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.