Skip to content
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

Closed
wants to merge 6 commits into from

Conversation

ionenwks
Copy link
Contributor

@ionenwks ionenwks commented May 7, 2022

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):

  • fixed logic for ~x86
  • check g++ rather than gcc in dxvk's crossdev-mingw, error is cryptic if cross has USE=-cxx, also check posix threads on both compilers if multilib (but really, just use mingw64-toolchain instead 👀)
  • renamed dlltool patch, name was misleading
  • added mingw's idl compiler (widl), so that packages that use it (e.g. vkd3d-proton), don't need to depend on wine to build
  • changed i686 wrappers to use full paths
  • no longer install dxvk tests
  • did some re-arrangement to mingw64-runtime, and now building native tools + gets widl as well
  • added vkd3d-proton 👀
  • add missing die for vkd3d-proton widl check
  • build in source dir for mingw64-runtime tools like the rest, simplifies (only headers need out of source)
  • unset toolchain vars for mingw64-runtime when cross-compiling like other ebuilds (e.g. CC=clang will build tools with clang, then switch to mingw-gcc rather than just fail)

(and seems ready now, have another thing planned but that will take a while, so let's merge this to get some testing in)

@gentoo-bot gentoo-bot added new package The PR is adding a new package. self-maintained The PR changes only packages that are maintained by the submitter (i.e. no need to ask anybody else) assigned PR successfully assigned to the package maintainer(s). labels May 7, 2022
@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2022-05-07 07:30 UTC
Newest commit scanned: f03162e
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/d7971e7d3b/output.html

@stefson
Copy link
Contributor

stefson commented May 7, 2022

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?

@ionenwks
Copy link
Contributor Author

ionenwks commented May 7, 2022

so this is kind of an umbrella ebuild to replace the whole of crossdev mingw setup?

yes

in any case, do you care to add the patch to all affected versions of dev-util/mingw64-runtime as well?

mingw64-runtime is not affected given it never enables lib32 and lib64 at same time

@stefson
Copy link
Contributor

stefson commented May 7, 2022

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?

@ionenwks
Copy link
Contributor Author

ionenwks commented May 7, 2022

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.

@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2022-05-08 03:31 UTC
Newest commit scanned: 00b7912
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/b2d91048e0/output.html

@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2022-05-08 14:16 UTC
Newest commit scanned: 92b987d
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/ef57d98964/output.html

@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2022-05-09 18:16 UTC
Newest commit scanned: 2613443
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/3187a7de71/output.html

@ionenwks ionenwks changed the title dev-util/mingw64-toolchain + app-emulation/dxvk new packages dev-util/mingw64-toolchain + dxvk + vkd3d-proton new packages [please reassign] May 10, 2022
@gentoo-bot gentoo-bot changed the title dev-util/mingw64-toolchain + dxvk + vkd3d-proton new packages [please reassign] dev-util/mingw64-toolchain + dxvk + vkd3d-proton new packages May 10, 2022
@gentoo-bot
Copy link

Pull Request assignment

Submitter: @ionenwks
Areas affected: ebuilds
Packages affected: app-emulation/dxvk, app-emulation/vkd3d-proton, dev-util/mingw64-runtime, dev-util/mingw64-toolchain

app-emulation/dxvk: @gentoo/proxy-maint (new package)
app-emulation/vkd3d-proton: @gentoo/proxy-maint (new package)
dev-util/mingw64-runtime: @ionenwks, @gentoo/toolchain
dev-util/mingw64-toolchain: @gentoo/proxy-maint (new package)

Linked bugs

Bugs linked: 644556, 664310


In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of ConductCopyright policy (expl.) ● DevmanualGitHub PRsProxy-maint guide

@gentoo-bot gentoo-bot added new package The PR is adding a new package. self-maintained The PR changes only packages that are maintained by the submitter (i.e. no need to ask anybody else) assigned PR successfully assigned to the package maintainer(s). bug linked Bug/Closes found in footer, and cross-linked with the PR. and removed new package The PR is adding a new package. assigned PR successfully assigned to the package maintainer(s). self-maintained The PR changes only packages that are maintained by the submitter (i.e. no need to ask anybody else) labels May 10, 2022
@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2022-05-10 08:21 UTC
Newest commit scanned: c8de8e6
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/256a437910/output.html

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>
@gentoo-repo-qa-bot
Copy link
Collaborator

Pull request CI report

Report generated at: 2022-05-13 02:45 UTC
Newest commit scanned: 330eab1
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/f2813b75c2/output.html

@ionenwks ionenwks deleted the mingw branch July 10, 2022 01:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assigned PR successfully assigned to the package maintainer(s). bug linked Bug/Closes found in footer, and cross-linked with the PR. new package The PR is adding a new package. self-maintained The PR changes only packages that are maintained by the submitter (i.e. no need to ask anybody else)
Projects
None yet
4 participants