Can you bisect this to figure out which commit it is that breaks the game?

It's going to be a recent commit because it ran fine on master 3-5 days ago. I'll look into how to bisect and let you know what commit it is.

@doitsujin

I just installed random commits until I found the problem. Not sure if that's what you needed, but here you go:

32e1afc7a104b837b3440a58b4a49640c401e511 - compiles, game works
e5fa55cbb5fac2761b1e85e5d8008bf49ecea4c4 - compiles, game crashes

I'm using this ebuild - https://raw.githubusercontent.com/pchome/dxvk-gentoo-overlay/master/app-emulation/dxvk/dxvk-9999.ebuild

Meson is at 0.49.2, GCC is 9.1.0.

@tsalwierz I have a similar problem with a similar ebuild and the same bisected patch (e5fa55c).
But when I build with the package-release.sh script, instead of the ebuild, I've no problem at all.

Can you try to build with the package-release.sh script and see if it's OK?

Looks like the ebuild you're using is producing winelib builds. Seems the issue is localized to that.

Forced -Dunity=on comes in mind.

EDIT: I don't own the game to check, but looks like forcing -O2 and don't using meson unity builds is still the case. See #798

EDIT2: D9VK, btw, more sensitive. I using forced -O2 for it, otherwise it became broken randomly (winelib).

@pchome
I have an extra copy if you want the game.

@tsalwierz
Thanks, but RTS (it's RTS ?) is not my thing. I don't going to use it other than for testing.

Could you check if this bug caused by unity build?
This build type greatly reduces DXVK compilation time, and I using this by default despite all earlier detected problems. So, maybe it worth to disable unity, and force -O2 for safety.

@pchome
That's a negative, forcing -Dunity=on -O2 after the flag parameters did nothing.

https://github.com/pchome/dxvk-gentoo-overlay/commit/382d1e09dc4cd2cfc2ce4f8f33ae73168e0888f0
Ebulds w/ unity set to off and forced -O2 (also there is experimental openvr USE flag, set if you have VR, not planned but ...).

Also, ebuild append your *FLAGS to default DXVK's, like

sed -E \
    -e "s#^(c_args.*)#\1 + $(_meson_env_array "${CFLAGS}")#" \
    -e "s#^(cpp_args.*)#\1 + $(_meson_env_array "${CXXFLAGS}")#" \
    -e "s#^(cpp_link_args.*)#\1 + $(_meson_env_array "${LDFLAGS}")#" \
    -i build-wine$(bits).txt || die

EDIT: everything else should be exactly similar to mentioned package-release.sh script.

@pchome no joy. dxvk-9999-r1 has the same issue.

@tsalwierz
Could you gist emerge --info app-emulation/dxvk?

Otherwise I can only blame -fvisibility=hidden flag.

@pchome

https://gist.github.com/tsalwierz/d3df1030e80c8a2062f4f36fe41ab239

That's really strange. If you use standard meson release build -- it should differ to your flags only for -march=native -pipe -fomit-frame-pointer (AFAIK meson release uses -O3 flag only).

@edmondo
I suppose we still talking about winelib build for package-release.sh.

@tsalwierz
So the ebuild, other than appending your flags to default flags from cross-file, should do the same things as package-release.sh.

Let's continue investigations tomorrow, I have no ideas for now.

@pchome yes, I only use winelib. I built it with:
./package-release.sh master /home/edmondo/tmp/dxvk --winelib
I had the issue with ELEX, freezing on the main menu. Problem is, I cannot reproduce anymore the issue with the ebuild. So my information is sadly not very reliable.

Just to confirm e1610f8 did fix the problem @doitsujin