New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dev-util/mingw64-toolchain + dxvk + vkd3d-proton new packages #25365
Conversation
Pull request CI reportReport generated at: 2022-05-07 07:30 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
so this is kind of an umbrella ebuild to replace the whole of crossdev mingw setup? in any case, do you care to add the patch to all affected versions of dev-util/mingw64-runtime as well? |
yes
mingw64-runtime is not affected given it never enables lib32 and lib64 at same time |
I see, you have full multilib support implemented - that would be helpfull to not juggle with two different toolchains at the same time if wine multilib is desired. Maybe you can avoid the patch if you update to binutils-2.38-r2, which has the fix for the dlltool breakage? |
Primary intend is to simplify this for users, not for the ebuild. I personally think ebuilds should support both ways to build for users that are happy with their crossdev setups and default to mingw64-toolchain given that will be more reliable (not that I plan to keep my crossdev mingw around, so I have no strong feelings there). The patch is unrelated to binutils, and only mingw64-runtime-10.0.0 is affected (build system picks temporary files to use with dlltool but they clash when building with --enable-lib32 and lib64 at same time), it'll be gone next version given it's a backport. |
Pull request CI reportReport generated at: 2022-05-08 03:31 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Pull request CI reportReport generated at: 2022-05-08 14:16 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Pull request CI reportReport generated at: 2022-05-09 18:16 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Pull Request assignmentSubmitter: @ionenwks app-emulation/dxvk: @gentoo/proxy-maint (new package) Linked bugsIn order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
Pull request CI reportReport generated at: 2022-05-10 08:21 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
This package attempts to bootstrap a mingw toolchain (binutils+gcc+mingw64-runtime) without crossdev for easy use with wine and related packages like dxvk. crossdev is generally intended for advanced use, and not for a user who just want to play games (e.g. many Blizzard games don't work without USE=mingw on wine). Not the greatest solution, but should allow improving the wine situation for users until there's a better option. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Many want to build this, but crossdev requirement made it unsuitable for ::gentoo. Now, mingw64-toolchain is there to remedy this and so let's add it. crossdev can still be used if USE=crossdev-mingw Note that unlike most overlays, this intentionally does not modify config.cpp and then installs dxvk.conf as a documentation example. Use the intended ${PWD}/dxvk.conf or DXVK_CONFIG_FILE env var. Paths are also different (using lib64 is not necessary and requires workarounds), so may need to update WINEPREFIX symlinks. Closes: https://bugs.gentoo.org/664310 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Mostly just style, but also now checking tuples again to ensure more deterministic results (e.g. a cpp check gone wrong could give 32bit despite x86_64 tuple), then fallback on the cpp check rather than die like tuple check formerly did. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Non-native USE=tools never made much sense, If a package is cross-compiling for mingw using e.g. widl, it'll need to be able to run the tool. This also prevents build failure (bug #644556) during bootstrap given this won't be trying to link with mingw (note that can cross-emerge mingw64-runtime for old behavior). wrt widl, it is provided by wine but that is a heavy dependency and some upstreams (e.g. vkd3d-proton) default to using *-w64-mingw32-widl instead -- small tool so may as well install it. Closes: https://bugs.gentoo.org/644556 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Complement to app-emulation/dxvk that's setup very similarly. Contains a lot of improvements over regular vkd3d for Proton but (like dxvk) can be used by any Wine. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
i.e. it could be CC=x86_64-pc-linux-gnu-gcc / clang which is what's wanted for building tools, but after we need to discard that to switch to x86_64-w64-mingw32-gcc (unless CHOST is already mingw as it would be correct). Ideally would need a unified way to do this with override variables for users to specify the alternate toolchain variables. The -Wl,--hash-style=* filter is likely not necessary given strip-unsupported-flags already strip it, but if(?) CC was set it may possibly have messed with that -- albeit will keep it as a safety/informational. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Pull request CI reportReport generated at: 2022-05-13 02:45 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Tossing this here first for a bit if anyone has suggestions or spot anything off.
mingw64-toolchain support in wine's ebuilds can be handled after it's merged/tested (all it needs is BDEPEND on
dev-util/mingw64-toolchain[${MULTILIB_USEDEP}]
+PATH=${BROOT}/usr/lib/mingw64-toolchain:${PATH}
and it'll build -- albeit ebuild does has_version cross-* then die atm, in dxvk's ebuild I still allow crossdev through USE=crossdev-mingw).(still doing some testing, likely not final --
haven't tried x86 yet too)Edit (changelog):
(and seems ready now, have another thing planned but that will take a while, so let's merge this to get some testing in)