| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit b7d87db08fa3899fd607a2f0d8137a35241b446f.
Fixing in mingw64-toolchain instead, *could* keep the workaround
longer for those that didn't update but likely doesn't affect many.
Bug: https://bugs.gentoo.org/932319
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/932319
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
strip-unsupported-flags handles this fine in LDFLAGS, but -Wl,*
are no-ops during compile-only tests (thus not stripped) and then
if a package compiles and links anything at same time it fails.
This used not to be a big problem but now that 23.0 profiles
do -Wl,-z,pack-relative-relocs (mingw ld has no -z) this is
hitting bashrc-mv users that tend to do CFLAGS="${LDFLAGS}"
by default. Tempting to ignore it because of how wrong it is,
but well.
An alternate route could be to eventually have strip-flags
and/or strip-unsupported-flags remove -Wl,* from non-LDFLAGS
given this could affect more than mingw (e.g. switching to
bfd when there is a lld-only option).
Bug: https://bugs.gentoo.org/928038
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
mingw64-*-11 been gone for a while now.
Was originally thinking to add the same workaround as mingw64-toolchain
for -Wl,-z,* but meson does not need this. So isntead cleaning this up.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
| |
wrt static, these are now passed unconditionally for windows platform.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently it will try to install both 32bit and 64bit dlls
in system32. Very few likely use wow64 so far, but this could
come biting later without a revbump.
Ideally do not want to use these scripts anymore and write
something new that could be packaged separately and shared
between dxvk, vkd3d-proton, and potential new packages.
Albeit haven't explored the cleanest way to do this yet,
so just do a dirty sanity check + fallback for now (wish
could just use these directly from system paths, but wine
really does not seem to offer a way to do this).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
Not known to have caused issues with vkd3d-proton in particular
(so skipping revbump), but believed to be too unsafe at the moment
and should use it at least for future rebuilds/bumps.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Will update the old ebuilds eventually but given this triggers
a rebuild with --changed-use (default enabled), will wait till
a bump and maybe stable to give a chance for people to update.
Note that USE=debug is still used to enable tracing here, part
of why these should ideally be separate flags.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trying a new snapshot, hopefully it works better than the last.
Done because a newer one is needed for d3d11on12 when using >=dxvk-2.2.
Note that this adds a new dx12core.dll and requires re-running the
setup script on old prefixes that were relying on symlinks to install
it (there is a postinst note about it as well).
Power users of dx12 are welcome to suggest better snapshots until
get an actual release (can experiment with -9999), mostly only doing
basic tests here. Not to say 2.8 or original vkd3d may not be the only
one that works with some games.
Bug: https://bugs.gentoo.org/904660
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* -fstack-clash-protection (bug #758914): ICE was fixed, if still
run into this then updating gcc to a newer _p* snapshot should
sort it (alternatively, use released >=gcc-13.1.0)
* -fstack-protector* (bug #870136): mingw64-runtime-11.0.0 adds
its own (partial) ssp support, allowing -D_FORTIFY_SOURCE=3 and
-fstack-protector-strong without libssp. Using these to build
Wine currently still leads to failure, but we can allow it here.
Bug: https://bugs.gentoo.org/758914
Bug: https://bugs.gentoo.org/870136
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
This matches the version used by Proton-8.0.1c, providing
to match expectations of advertised proton bug fixes and
will only be kept until there's a new vkd3d-proton release.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
| |
Will not keep it forever, but stabilizing this older version as
well given 2.7 requires more recent vulkan drivers to function.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
| |
No real reason to keep this ~arch only, and will be
convenient for stable Wine users.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
Unsure if it's exact same requirements (not as well documented),
but 2.7 is definitely not usable with nvidia-drivers:0/470 while
2.6 still works.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
| |
Thanks-to: Akash Paul <paul007-dev@outlook.com>
Closes: https://github.com/gentoo/gentoo/pull/28472
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
Does not really feel useful, ultimately this can be used in
many ways (including custom wines, or perhaps not even wine)
and trying to check does not mean much.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|