runtime text relocations /usr/lib/dxvk/d3d{9,10,11}.dll.so #5

New Issue

stefson · 2020-03-21T12:43:54+01:00

stefson commented

2020-03-21 12:43:54 +01:00

hey there, I wonder if you also get these warnings from portage:

QA Notice: The following files contain runtime text relocations
Text relocations force the dynamic linker to perform extra
work at startup, waste system resources, and may pose a security
risk. On some architectures, the code may not even function
properly, if at all.
For more information, see:
https://wiki.gentoo.org/wiki/Hardened/HOWTO_locate_and_fix_textrels
Please include the following list of files in your report:
TEXTREL usr/lib/dxvk/d3d9.dll.so
TEXTREL usr/lib/dxvk/d3d10_1.dll.so
TEXTREL usr/lib/dxvk/d3d10.dll.so
TEXTREL usr/lib/dxvk/d3d10core.dll.so
TEXTREL usr/lib/dxvk/d3d11.dll.so
TEXTREL usr/lib/dxvk/dxgi.dll.so

I do get them with both dxvk-1.5.5 and master using wine-vanilla-5.2

Is this a bug in winelib, in ld.bfd, or what is this? Is it important to fix?

upstreams dxvk closed the issue as NOTMYBUG, or something along the lines ;-)

hey there, I wonder if you also get these warnings from portage: * QA Notice: The following files contain runtime text relocations * Text relocations force the dynamic linker to perform extra * work at startup, waste system resources, and may pose a security * risk. On some architectures, the code may not even function * properly, if at all. * For more information, see: * * https://wiki.gentoo.org/wiki/Hardened/HOWTO_locate_and_fix_textrels * * Please include the following list of files in your report: * TEXTREL usr/lib/dxvk/d3d9.dll.so * TEXTREL usr/lib/dxvk/d3d10_1.dll.so * TEXTREL usr/lib/dxvk/d3d10.dll.so * TEXTREL usr/lib/dxvk/d3d10core.dll.so * TEXTREL usr/lib/dxvk/d3d11.dll.so * TEXTREL usr/lib/dxvk/dxgi.dll.so I do get them with both dxvk-1.5.5 and master using wine-vanilla-5.2 Is this a bug in winelib, in ld.bfd, or what is this? Is it important to fix? upstreams dxvk closed the issue as NOTMYBUG, or something along the lines ;-)

tastytea commented

2020-03-21 13:48:46 +01:00

I do get the same warnings but always ignored them. 😄

I don't know much about the topic, but I had a look with scanelf -qT /usr/lib/dxvk/*.so and it seems the TEXTRELs happen in functions starting with __wine_spec, which belong to wine. The binaries provided by upstream do not contain TEXTRELs, as far as I can see.

It seems they are False positives that happened because the code was not compiled with -fPIC. I'll run a few tests and update the ebuilds soon.

I do get the same warnings but always ignored them. :smile: I don't know much about the topic, but I had a look with `scanelf -qT /usr/lib/dxvk/*.so` and it seems the TEXTRELs happen in functions starting with `__wine_spec`, which belong to wine. The binaries provided by upstream do not contain TEXTRELs, as far as I can see. It seems they are [False positives](https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide#.22False.22_Positives) that happened because the code was not compiled with `-fPIC`. I'll run a few tests and update the ebuilds soon.

tastytea added the

bug

label 2020-03-21 13:49:04 +01:00

tastytea commented

2020-03-21 14:52:25 +01:00

Compiling with -fPIC did not solve this. I'll keep ignoring this until someone has a solution. 🙂

Compiling with `-fPIC` did not solve this. I'll keep ignoring this until someone has a solution. 🙂

tastytea added the

help wanted

label 2020-03-21 14:52:31 +01:00

stefson commented

2020-03-21 15:08:02 +01:00

May I ask, is it correct that the dxvk ebuild uses some kind of wine-gcc wrapper to compile the code? Since wine-vanilla shows around a gazillion of these textrel warnings in it's own src_install, it might be a bug from these wine compiler, ending up here?

tastytea commented

2020-03-21 15:29:45 +01:00

Yes, the ebuild uses wineg++ which is a g++ wrapper (see man wineg++).

I also think that the bug comes from wine (since upstream's build is fine) but I'm not sure.

Yes, the ebuild uses `wineg++` which is a `g++` wrapper (see `man wineg++`). I also think that the bug comes from wine (since upstream's build is fine) but I'm not sure.

stefson commented

2020-03-21 15:53:28 +01:00

well, it seems as if the maintainers intend to entirely drop support for source builds with wineg++ ; right now it's untested and bugs are fixed, but it might be mandantory soon to use mingw-w64.

found that information via https://github.com/doitsujin/dxvk/issues/1521

well, it seems as if the maintainers intend to entirely drop support for source builds with wineg++ ; right now it's untested and bugs are fixed, but it might be mandantory soon to use mingw-w64. found that information via https://github.com/doitsujin/dxvk/issues/1521

tastytea commented

2020-03-21 17:55:25 +01:00

Yeah, I'm aware (I ran into the bug you linked). Trying to make an ebuild with Mingw (or make a dxvk-bin ebuild if I fail) is on my todo-list.

stefson commented

2020-03-21 21:31:23 +01:00

well, the gentoo wiki article for mingw is outdated, that's for sure :-/

stefson commented

2020-03-22 07:52:49 +01:00

to save you some time:

1. bootstrap with crossdev (crossdev -S x86_64-w64-mingw32)
 -> I'm fairly cartain that this is needed: echo "cross-x86_64-w64-mingw32/gcc -fortran -vtv -sanitize" >> /etc/portage/package.use/cross-x86_64-w64-mingw32 
 -> you must keyword cross-x86_64-w64-mingw32/mingw64-runtime manually to your arch in your systems package.keywords, otherwise the bootstrap will stall. This is a minor bug in crossdev

2. if bootstrapping is done, rebuild cross-x86_64-w64-mingw32/mingw64-runtime with: 
USE="libraries idl tools -selinux -multilib" (not sure if needed)

3. right now, the cross-x86_64-w64-mingw32/gcc doesn't have posix support. so rebuild cross-x86_64-w64-mingw32/gcc one last time with: EXTRA_ECONF="--enable-threads=posix" emerge -1 cross-x86_64-w64-mingw32/gcc -av

that's it, with this toolchain it's possible to follow the instructions from the dxvk github page, as in: 

git clone repo && meson --cross-file build-win64.txt --buildtype release --prefix /usr build.w64 && ninja -jN && ninja install

tested with this toolchain on amd64: 

cross-x86_64-w64-mingw32/binutils-2.33.1-r1
cross-x86_64-w64-mingw32/mingw64-runtime-7.0.0-r1
cross-x86_64-w64-mingw32/gcc-9.2.0-r2

to save you some time: ``` 1. bootstrap with crossdev (crossdev -S x86_64-w64-mingw32) -> I'm fairly cartain that this is needed: echo "cross-x86_64-w64-mingw32/gcc -fortran -vtv -sanitize" >> /etc/portage/package.use/cross-x86_64-w64-mingw32 -> you must keyword cross-x86_64-w64-mingw32/mingw64-runtime manually to your arch in your systems package.keywords, otherwise the bootstrap will stall. This is a minor bug in crossdev 2. if bootstrapping is done, rebuild cross-x86_64-w64-mingw32/mingw64-runtime with: USE="libraries idl tools -selinux -multilib" (not sure if needed) 3. right now, the cross-x86_64-w64-mingw32/gcc doesn't have posix support. so rebuild cross-x86_64-w64-mingw32/gcc one last time with: EXTRA_ECONF="--enable-threads=posix" emerge -1 cross-x86_64-w64-mingw32/gcc -av that's it, with this toolchain it's possible to follow the instructions from the dxvk github page, as in: git clone repo && meson --cross-file build-win64.txt --buildtype release --prefix /usr build.w64 && ninja -jN && ninja install tested with this toolchain on amd64: cross-x86_64-w64-mingw32/binutils-2.33.1-r1 cross-x86_64-w64-mingw32/mingw64-runtime-7.0.0-r1 cross-x86_64-w64-mingw32/gcc-9.2.0-r2 ```

stefson commented

2020-03-22 09:07:35 +01:00

possible shortcut:

1. crossdev -S x86_64-w64-mingw32
-> you must keyword cross-x86_64-w64-mingw32/mingw64-runtime manually to your arch in your systems package.keywords, otherwise the bootstrap will stall. This is a minor bug in crossdev

2. if bootstrapping is done, rebuild cross-x86_64-w64-mingw32/mingw64-runtime with: 
USE="libraries -idl -tools -selinux -multilib" (you will run into pthreads.h errors without libaries, idl and tools are not needed) 

-> it might be possible to avoid the recompiling by bootstraping the mingw64-runtime with libraries to begin with

3. for posix support, rebuild cross-x86_64-w64-mingw32/gcc one last time with: EXTRA_ECONF="--enable-threads=posix" emerge -1 cross-x86_64-w64-mingw32/gcc -av

possible shortcut: ``` 1. crossdev -S x86_64-w64-mingw32 -> you must keyword cross-x86_64-w64-mingw32/mingw64-runtime manually to your arch in your systems package.keywords, otherwise the bootstrap will stall. This is a minor bug in crossdev 2. if bootstrapping is done, rebuild cross-x86_64-w64-mingw32/mingw64-runtime with: USE="libraries -idl -tools -selinux -multilib" (you will run into pthreads.h errors without libaries, idl and tools are not needed) -> it might be possible to avoid the recompiling by bootstraping the mingw64-runtime with libraries to begin with 3. for posix support, rebuild cross-x86_64-w64-mingw32/gcc one last time with: EXTRA_ECONF="--enable-threads=posix" emerge -1 cross-x86_64-w64-mingw32/gcc -av ```

stefson commented

2020-03-22 09:43:20 +01:00

the ebuild doesn't seem difficult to fix:

redirect source meson cross file to ${S}/build-win64.txt and maybe alter your sed kungfu a bit ;-)

optional: strip binaries/libs with mingw32 cross strip

untested: updating WINEPREFIX with setup_dxvk.sh

the ebuild doesn't seem difficult to fix: redirect source meson cross file to ${S}/build-win64.txt and maybe alter your sed kungfu a bit ;-) optional: strip binaries/libs with mingw32 cross strip untested: updating WINEPREFIX with setup_dxvk.sh

tastytea commented

2020-04-21 05:51:00 +02:00

Thanks for your help and sorry for the delay. I ran some tests and this seems to be the shortest recipe:

echo '~cross-x86_64-w64-mingw32/mingw64-runtime-7.0.0 ~amd64' >> /etc/portage/package.accept_keywords/mingw
crossdev --stable --target cross-x86_64-w64-mingw32
echo 'EXTRA_ECONF="--enable-threads=posix"' >> /etc/portage/env/mingw-gcc.conf
echo 'cross-x86_64-w64-mingw32/gcc mingw-gcc.conf' >> /etc/portage/package.env/mingw
echo 'cross-x86_64-w64-mingw32/mingw64-runtime libraries' >> /etc/portage/package.use/mingw
emerge --oneshot cross-x86_64-w64-mingw32/gcc cross-x86_64-w64-mingw32/mingw64-runtime

I pushed app-emulation/dxvk-1.6.1-r1 with mingw support. Can you test if it works?

It builds here but I have not verified if it is usable yet.

Thanks for your help and sorry for the delay. I ran some tests and this seems to be the shortest recipe: ``` bash echo '~cross-x86_64-w64-mingw32/mingw64-runtime-7.0.0 ~amd64' >> /etc/portage/package.accept_keywords/mingw crossdev --stable --target cross-x86_64-w64-mingw32 echo 'EXTRA_ECONF="--enable-threads=posix"' >> /etc/portage/env/mingw-gcc.conf echo 'cross-x86_64-w64-mingw32/gcc mingw-gcc.conf' >> /etc/portage/package.env/mingw echo 'cross-x86_64-w64-mingw32/mingw64-runtime libraries' >> /etc/portage/package.use/mingw emerge --oneshot cross-x86_64-w64-mingw32/gcc cross-x86_64-w64-mingw32/mingw64-runtime ``` I pushed `app-emulation/dxvk-1.6.1-r1` with mingw support. Can you test if it works? It builds here but I have not verified if it is usable yet.

tastytea commented

2020-04-21 19:28:49 +02:00

setup_dxvk.sh works, playing a game works, the live-ebuild is now updated too. Please reopen if you have any issues.

winegcc is officially no longer supported by upstream btw: https://github.com/doitsujin/dxvk/commit/436357e28096f5e1e25aa8b72fceb77123ea8404.

setup_dxvk.sh works, playing a game works, the live-ebuild is now updated too. Please reopen if you have any issues. winegcc is officially no longer supported by upstream btw: <https://github.com/doitsujin/dxvk/commit/436357e28096f5e1e25aa8b72fceb77123ea8404>.

tastytea closed this issue

2020-04-21 19:28:49 +02:00

stefson commented

2020-04-25 06:37:15 +02:00

Yes, it does work pretty good now with mingw :)

P.S: wine-5.6 ships with a broken winecfg, had to work around that first before testing your stuff

Yes, it does work pretty good now with mingw :) P.S: wine-5.6 ships with a broken winecfg, had to work around that first before testing your stuff

Sign in to join this conversation.