tastytea/overlay
tastytea/overlay
Archived
2
1
Fork 3
Code Issues Pull Requests Releases Wiki Activity

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

New Issue
Closed
opened 2020-03-21 12:43:54 +01:00 by stefson · 13 comments
stefson commented 2020-03-21 12:43:54 +01:00
Copy Link

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
Owner
Copy Link

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
Owner
Copy Link

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
Author
Copy Link

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?

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
Owner
Copy Link

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
Author
Copy Link

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
Owner
Copy Link

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.

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
Author
Copy Link

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

well, the gentoo wiki article for mingw is outdated, that's for sure :-/
stefson commented 2020-03-22 07:52:49 +01:00
Author
Copy Link

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
Author
Copy Link

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
Author
Copy Link

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
Owner
Copy Link

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
Owner
Copy Link

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>.
stefson commented 2020-04-25 06:37:15 +02:00
Author
Copy Link

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
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
question
More information is needed
spam
wontfix
This won't be fixed
No Label
bug
help wanted
Milestone
No items
No Milestone
Assignees
Clear assignees
tastytea
No Assignees
2 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: tastytea/overlay#5
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?