Are you current proton_4.11 (3454fff) or some other branch? Have you tried re-creating the VM after the changes (sorry, I know it's a hassle)? If yes to both, can you paste any errors you get here?

So I finally got around to doing some more digging on this. Up until now my builds have been working because as it turns out, I've been skipping using both the previous schroot cross-cc method and the current custom build.

When I would make my builds, I would run:

mkdir ~/build/
cd ~/build
../proton/configure.sh --steam-runtime64=docker:steam-proton-dev --steam-runtime32=docker:steam-proton-dev32 --steam-runtime=$HOME/steam-runtime/runtime/ --with-ffmpeg --build-name=SOME_NAME

This was the older 3.x method. By doing this I was essentially skipping the makefile configure:

CONFIGURE_CMD := ../proton/configure.sh \
	--steam-runtime64=docker:steam-proton-dev --steam-runtime32=docker:steam-proton-dev32 \
	--steam-runtime="$$HOME"/steam-runtime/runtime/ \
	--build-name="$(_build_name)" \
	--docker-opts=-v\ /srv/chroot:/srv/chroot\ -v\ /etc/schroot/chroot.d/proton_crosscc:/etc/schroot/chroot.d/proton_crosscc\ -v\ /home/vagrant/rbind_fstab:/etc/schroot/default/fstab

This of course skips the cross cc method altogether and just uses the default mingw on the vagrant VM, which actually worked despite the noted disadvantages.

So, I tried to rectify this by instead, running:

build_name=SOME_NAME make dist

within the proton folder, as it's supposed to be done. This -did- trigger the schroot method, however again, nothing launches. The same symptom as the title.

So, I updated my build environment to the current system, which updates to the posix versions, then compiles mingw with patches and set itself as default, and removes the system installed versions.

Again, my build compiles, but nothing launches... nothing really shows up in the logs except:

wine: Unhandled page fault on execute access to 0032D8E0 at address 0032D8E0 (thread 0009), starting debugger...

Full log attached:
steam-230410.log

So the question is - why is the system build working, but the custom build not working? I must've rebuilt both set ups half a dozen times before figuring out that it was the custom version that was failing.

So I went into the vm. I first decided to check the alternatives 'which' output that was used:

$ which x86_64-w64-mingw32-gcc-posix
<no output>
$ which x86_64-w64-mingw32-g++-posix
<no output>
$ which i686-w64-mingw32-gcc-posix
<no output>
$ which i686-w64-mingw32-g++-posix
<no output>

Presumably this was because mingw was removed at the end of the script. Our custom build version still existed:

$ which i686-w64-mingw32-g++
/home/vagrant/.local/bin/i686-w64-mingw32-g++

So, I reinstalled:

          gcc-mingw-w64-i686 gcc-mingw-w64-x86-64
          g++-mingw-w64-i686 g++-mingw-w64-x86-64

I re-ran

      update-alternatives --set x86_64-w64-mingw32-gcc `which x86_64-w64-mingw32-gcc-posix`
      update-alternatives --set x86_64-w64-mingw32-g++ `which x86_64-w64-mingw32-g++-posix`
      update-alternatives --set i686-w64-mingw32-gcc `which i686-w64-mingw32-gcc-posix`
      update-alternatives --set i686-w64-mingw32-g++ `which i686-w64-mingw32-g++-posix`

I removed and re-ran the custom mingw build:

rm -R "$HOME/.local/" (note, I ran ls -la in here to check if anything other than mingw files was here before removing)
mkdir -p $HOME/mingw-w64-build/
cd $HOME/mingw-w64-build && $HOME/proton/build-mingw-w64.sh "$HOME/.local/"
rm -rf $HOME/mingw-w64-build/

I checked that our posix and custom versions were there again:

$ which i686-w64-mingw32-g++-posix                                                     
/usr/bin/i686-w64-mingw32-g++-posix
$ which i686-w64-mingw32-g++
/home/vagrant/.local/bin/i686-w64-mingw32-g++

Then, I ran another build to see if it made any difference with the mingw system packages still installed and the posix versions set. I did notice that posix was set in the custom build's configuration files.. so at first I didn't think this mattered:

        mkdir -p gcc/
        pushd gcc/
        ...
                            --enable-threads=posix \

Watching the build, I noticed as expected DXVK used the custom build:

Cross C compiler: i686-w64-mingw32-gcc (gcc 9.2.0)
Cross C++ compiler: i686-w64-mingw32-g++ (gcc 9.2.0)
Program i686-w64-mingw32-windres found: YES (/home/vagrant/.local/bin/i686-w64-mingw32-windres)

Build finishes. Still does not launch.
steam-230410.log

Tried removing the prefix, no luck.

Ok, so, what if we remove the custom mingw build entirely, and just use the system ones?

sudo apt reinstall gcc-mingw-w64-i686 gcc-mingw-w64-x86-64 g++-mingw-w64-i686 g++-mingw-w64-x86-64
rm -R ~/.local

Quick check for default paths:

$ which i686-w64-mingw32-g++-posix
/usr/bin/i686-w64-mingw32-g++-posix

$ which i686-w64-mingw32-g++
/usr/bin/i686-w64-mingw32-g++

$ which i686-w64-mingw32-gcc
/usr/bin/i686-w64-mingw32-gcc

$ which i686-w64-mingw32-gcc-posix
/usr/bin/i686-w64-mingw32-gcc-posix

$ which x86_64-w64-mingw32-gcc-posix
/usr/bin/x86_64-w64-mingw32-gcc-posix

$ which x86_64-w64-mingw32-gcc
/usr/bin/x86_64-w64-mingw32-gcc

$ which x86_64-w64-mingw32-g++
/usr/bin/x86_64-w64-mingw32-g++

$ which x86_64-w64-mingw32-g++-posix
/usr/bin/x86_64-w64-mingw32-g++-posix

aaand we run the build again.

build_name=SOME_NAME make redist

ensure DXVK is using the default system mingw:

Cross C compiler: i686-w64-mingw32-gcc (gcc 8.3.0)
Cross C++ compiler: i686-w64-mingw32-g++ (gcc 8.3.0)
Program i686-w64-mingw32-windres found: YES (/usr/bin/i686-w64-mingw32-windres)

Build finishes again. GUESS WHAT, IT RUNS!

So - it's definitely an issue with the custom mingw build.

Currently the only relevant difference between my repo and stock proton is that I pull in Vanilla wine, and apply this patch for Steam compatibility:

https://github.com/GloriousEggroll/proton-ge-custom/blob/proton-ge-4.21/game-patches-testing/proton-valve-patches/proton-steamclient_swap.patch

This would not affect launching this game, as this game uses a launcher that does not use steam's library at all, and instead launches the game after updating, which the game itself then uses the library via -steam launch option.

The fact that the Launcher isn't even opening signals to me an issue with how wine was built with mingw.

More testing:
Tried proton custom mingw without binutils patches - problem still exists.

Will give another attempt tomorrow with completely clean proton pull and test a build with proton wine and my custom wine.

Sounds like something's gone wrong with the Wine update. With the broken build, can you upload a +relay,+server log?

I figured out the issue. In my build, I use these for WINE's LDFLAGS for wine to compile with faudio+ffmpeg:

https://github.com/ValveSoftware/Proton/pull/2082/commits/c2a2696cff7a6c1ad6bf3a1dd21b22d9eabee885

This doesnt play well with the custom mingw build and causes nothing to launch, however it's required for wine to detect faudio and ffmpeg's libraries during compilation. If I remove the flags then it works, but the ffmpeg libraries do not get detected, which faudio relies on.

This change was proposed after it was deemed a better solution than patching it into configure.ac in WINE directly, but I think that still may work:

https://github.com/ValveSoftware/wine/pull/36

Tagging @mat8913 and @kakra on this one for more input. It seems if we want this to work we may have to go the configure.ac route after all.

Note: This is also how I have it done in the lutris build environment.

This patch to WINE accomplishes the same thing without interfering with the custom Mingw build:

diff --git a/configure.ac b/configure.ac
index 5e36331596..8f4ad7627c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1741,7 +1741,7 @@ WINE_NOTICE_WITH(sdl,[test "x$ac_cv_lib_soname_SDL2" = "x"],
 dnl **** Check for FAudio ****
 if test "x$with_faudio" != "xno"
 then
-    WINE_PACKAGE_FLAGS(FAUDIO,[faudio],[-lFAudio],,,
+    WINE_PACKAGE_FLAGS(FAUDIO,[faudio],[-lFAudio -lavcodec -lavutil -lswresample],,,
         [AC_CHECK_HEADERS([FAudio.h],
             [WINE_CHECK_SONAME(FAudio,FAudioCreate,,,[$FAUDIO_LIBS],[[libFAudio*]])])
              WINE_CHECK_LIB_FUNCS([FAudio_CommitOperationSet \
diff --git a/configure b/configure
index 818d31d270..bb3c4b5fbd 100755
--- a/configure
+++ b/configure
@@ -13895,7 +13895,7 @@ if ${FAUDIO_LIBS:+false} :; then :
 fi
 fi
 
-FAUDIO_LIBS=${FAUDIO_LIBS:-"-lFAudio"}
+FAUDIO_LIBS=${FAUDIO_LIBS:-"-lFAudio -lavcodec -lavutil -lswresample"}
 $as_echo "$as_me:${as_lineno-$LINENO}: faudio cflags: $FAUDIO_CFLAGS" >&5
 $as_echo "$as_me:${as_lineno-$LINENO}: faudio libs: $FAUDIO_LIBS" >&5
 ac_save_CPPFLAGS=$CPPFLAGS

I noticed autoconf isn't run in the proton build and other patches to proton (for example amd_ags) apply to both configure and configure.ac., so I've updated the patch from ValveSoftware/wine#36 to include both. Obviously not merge-able until if/when ffmpeg is enabled, but at least it's another hurdle jumped.

Closing this as I've tested this with wine and it is working again:

LDFLAGS="-L$(abspath $(TOOLS_DIR64))/lib -Wl,-rpath-link,$(abspath $(TOOLS_DIR64))/lib" \