| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
| |
Signed-off-by: Michael Mair-Keimberger <mmk@levelnine.at>
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hard to tell what's actually needed, nvidia users do not need
it on mesa (or need mesa at all), mesa users do not need it on
nvidia, and multi-card users likely need it on both.
If do this through dependencies, *could* always depend on
mesa[abi_x86_32] even if it may be wrong, and depend on nvidia's
if USE=video_cards_nvidia -- but for now sticking to a warning.
Ultimately it's also kind of an optfeature, only needed if
running 32bit hardware accelerated applications and not needed
at build time.
Non-issue for users doing abi_x86_32 globally.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit b23fe7660928f72b2146770ae145a5f57012ef7c.
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: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
Not worth a revbump, rather few people disable that.
Also do [wayland?] for 9.8 and 9999, technically vulkan support
is pretty WIP so it's more or less a placeholder -- more correct
handling would be to require vulkan? ( X ) for now.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/931341
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Is an issue with both lld and bfd that I can see, likely due to
the linker tricks wine uses. Let's just filter it as it's fragile.
Skipping revbump given the option is rarely used and shouldn't
affect many.
Bug: https://bugs.gentoo.org/931329
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
| |
Unsure how much is broken, but for wine-7+8 it doesn't seem worth
the effort to backport. No issues I can see with wine-9.
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test-flags-CC was not meant to test LDFLAGS and -Wl,* are no-ops
at compile-time and thus don't get stripped even if they don't work
(same happens when using strip-unsupported-flags) 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).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
There is alternate realities where OpenGL works great for some, and is
1fps unusable for others (likely depending on what is being run and/or
drivers). So saying "slightly" may be misleading.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Unsure if the new wayland opengl support actually works (runtime
untested), but it at least builds now. Very new/experimental anyway.
Sorry for missing this during the bump, should've tried USE=wayland.
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: Matoro Mahri <matoro_gentoo@matoro.tk>
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
Not that this means that it works.
Logic was inverted in 9.0+ and I meant to correct it, but after
all I don't think I want to even care for this and users with
USE=custom-cflags are on their own.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 9.1+, wine defaults to using /dev/hidraw* for some extra gamepads,
most notably Sony DualShock4 which may come as unexpected. /dev/hidraw*
access is restricted to root by default leaving users with a situation
that seem like a wine regression.
Only a optfeature since most gamepads do not need this (xbox one,
about any 3rd party gamepads, etc...). Hopefully the optfeature is
noticed by affected users.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
| |
Last of the previous development cycle, there should
be no reason to need this over 9.0.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Or else it may come as confusing if users try to disable
USE=abi_x86_32 and then a dependency still requests it.
mingw64-toolchain is the only one needed, no need for glibc, gcc,
mesa/nvidia, gstreamer, etc... and it works even on no-multilib
profiles where the USE is unmasked.
There are alternatives to mingw64-toolchain, but let's not go
into confusing details in the USE desc.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
"WIP" does not feel entirely right anymore, albeit experimental
feels still fitting. Wine's announcement also mentions worse
performance so let's mention it here too.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
| |
Not touching 8.x (except 8.0.2) given 9.0 is soon, and these will
be dropped once new 9.1 development cycle starts.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
This reverts commit f2a99318b859e9365e51f1ba5c7553d6e05d590a.
This may not set LEX, but that's because wine does not respect
this variable in the first place and looks for flex directly.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
All of these will be using app-alternatives/lex anyway as they're not unsetting
YACC or LEX, so make the dep reflect reality.
(Included both YACC and LEX out of conservatism.)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
| |
File adds a .md extension, and fwiw use a wildcard so that
it can work with bit older commits too.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
Add a global USE=opencl flag. The flag is used consistently in 30
packages, and most of them do not provide any additional information
worth preserving.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
Upstream passes -mpreferred-stack-boundary=2 for x86 by default
now which should in theory resolve this.
If no issues, will likely replace -mno-avx in other mingw-using
packages like dxvk too (requires a x86-check, invalid for amd64).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|