protonscr

Issue building 32bit LTO'd dxvk with binutils 2.35.1

dxvkclosed build
doitsujin/dxvk#1782 · opened 2020-09-29 by FireBurn · updated 2021-06-21 · 11 comments · github
FFireBurn 2020-09-29 github

This is only on 32bit, and previously worked with 2.34

build.log

This is more of an FYI, I've reported the issue with Gentoo here https://bugs.gentoo.org/745372 and I'll try and find how to report it upstream with the binutils folk

FFireBurn 2020-09-29 github

I've also been maintaining a winelib build, this continues to build, it's only the mingw build that fails

Ddoitsujin maintainer 2020-09-29 github

Anything we can do to work around that? The linker error doesn't really make all that much sense to me since it involves the C++ standard library.

FFireBurn 2020-09-29 github

The work around if to not use LTO, or go back to an older version of ld.bfd, also reverting this commit https://github.com/bminor/binutils-gdb/commit/041d1c2d4f03a134cb7574e4d62d2ce4418503ff fixes it

Ddoitsujin maintainer 2020-09-30 github

We aren't using LTO by default though?

FFireBurn 2020-09-30 github

Then you're fine, I'll update the title

TTheGreatMcPain 2020-10-04 github

I can confirm that this binutils commit fixes this.

Ddoitsujin maintainer 2020-10-04 github

Thanks, do we know when the fix will make it into a release?

TTheGreatMcPain 2020-10-05 github

According to https://sourceware.org/bugzilla/show_bug.cgi?id=26675#c19 it should already be in 2.36.

GGloriousEggroll 2021-02-07 github

from the proton binutils script for build-mingw-w64.sh:

        pushd binutils/
            if [ ! -e Makefile ]; then
                ../../$BINUTILS_SRCDIR/configure \
                    --prefix=$DST_DIR/ \
                    --build=$BUILD_ARCH \
                    --host=$HOST_ARCH \
                    --target=$WIN32_TARGET_ARCH \
                    --enable-lto \
                    --enable-plugins \
                    --enable-deterministic-archives \
                    --disable-multilib \
                    --disable-nls \
                    --disable-werror \
                    $BINUTILS_EXTRA_CONFIGURE
            fi
            make $JOBS configure-host
            make $JOBS LDFLAGS=-all-static
            make $JOBS install
        popd

and from the gcc build options:

        pushd gcc/
            if [ ! -e Makefile ]; then
                #arguments mostly taken from Arch AUR mingw-w64-gcc PKGBUILD,
                #except "--disable-dw2-exceptions" swapped for "--disable-sjlj-exceptions --with-dwarf2"
                #for performance reasons on 32-bit
                LDFLAGS=-static PATH=$NEWPATH:$PATH ../../$GCC_SRCDIR/configure \
                    --prefix=$DST_DIR/ \
                    --build=$BUILD_ARCH \
                    --host=$HOST_ARCH \
                    --target=$WIN32_TARGET_ARCH \
                    --enable-static \
                    --enable-shared \
                    --enable-languages=c,lto,c++ \
                    --disable-multilib \
                    --enable-threads=posix \
                    --enable-fully-dynamic-string \
                    --enable-libstdcxx-time=yes \
                    --enable-libstdcxx-filesystem-ts=yes \
                    --enable-cloog-backend=isl \
                    --enable-libgomp \
                    --enable-lto \
                    --disable-sjlj-exceptions \
                    --with-dwarf2 \
                    $GCC_EXTRA_CONFIGURE
            fi
            PATH=$NEWPATH make $JOBS all-gcc
            PATH=$NEWPATH make $JOBS install-gcc
        popd

--enable-lto is set in the compile options for both, but this is for binutils, not dxvk.

I've just started looking into this as I have a user who claims upstream dxvk when compiled on arch works, but when compiled in proton hangs his vega APU in RE2. reverting https://github.com/doitsujin/dxvk/commit/742b52bbb566ede9fd638817b9d0a1e0c0f6b49b seems to fix it. but im not sure why it would not be affected on arch, but be affected in proton other than build environment differences

Nothing extracted yet.