| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Still setup from back when had x.x.9999 experimental branches.
Doesn't really matter but these ebuilds will be there for a while
and when comparing ebuilds it comes up as a distracting difference.
At same time, drop a no longer needed wildcard.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
| |
|
|
|
| |
Bug: https://bugs.gentoo.org/943849
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
And repeat it every time rather than just on first install through
the README.gentoo so that (hopefully) upstream Valve will not get
more bug reports from here.
Furthermore note that we also can't really do much about issues
either and users seeking support should use normal Wine or normal
Proton.
Bug: https://bugs.gentoo.org/943001
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 b701bf35fd508f2bc15c42805e7ab2ad131ff5f6.
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>
|
| |
|
|
|
|
| |
Not worth a revbump, rather few people disable that.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
No release yet but current 9.0.9999 builds fine as-is, and
would rather not worry about backporting for old branches.
Closes: https://bugs.gentoo.org/924486
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>
|
| |
|
|
|
| |
Closes: https://github.com/gentoo/gentoo/pull/34865
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 70004fc841b5b6e11ebd6393e0487e3c3171213a.
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Hard to know for sure if it's really used or not, but do not
want to introduce a kinda no-op VIDEO_CARDS on wine to actually
depend on it over a warning.
Less of an issue with mesa given other dependencies end up
requiring it (technically the dep is wrong given e.g. nvidia
would not need mesa[abi_x86_32], but well).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Upon further consideration 84924628f0009acbe92b94ac28141c7ee322548e
result in rather unexpected behavior even if we consider that
USE=custom-cflags is unsupported, and giving a way to skip -mno-avx
may not be all that worth it.
So revert plus tidy and add this bugref.
Closes: https://bugs.gentoo.org/912268
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Was silently ignored with <clang-16, but clang:17 now considers this
an error.
Working -mabi=ms would be required if --without-mingw, but with it
seems it gets used in install phase possibly(?) by mistake. As a
quick fix, drop the option for now. Prefer to leave alone for gcc,
so done in ebuild w/ tc-is-clang.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
| |
Technically needs a revbump, but given never got a bug report despite
being broken since forever I'll consider this low priority.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Don't recommend it (even hardly recommend -march=native!), but
some users like ricing their wine and would rather not see this
if it "works for me".
Others like filter-lto stay regardless given that just will not
build.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AVX issues with mingw-gcc aren't exactly new, e.g.
https://bugs.winehq.org/show_bug.cgi?id=45289
Been known to cause issues with dxvk too, albeit unsure
if that's still relevant as issues are scattered/lost.
Newly, >=wine-8.10 is likely to crash doing anything
at all 32bit if used -march=native (w/ avx) and 32bit
(e.g. `WINEARCH=win32 winecfg`).
Adding this to every packages using mingw as a precaution,
not believed there is much to gain from keeping AVX given
the fragility here. May revisit eventually with a newer GCC.
wine-proton is based on older wine and is not affected by
the obvious crash, this is a precaution for potential other
issues (so not revbumping over this, can wait till normal bump).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Mostly a dirty/quick hack, exact cause leading to this happening
with wine-proton-7(32bit) but not 8 nor 7(64bit) haven't been fully
dug into.
Had tested wine-vanilla-7.0.2 with 11.0.0 and initially thought
proton-7 was fine too, but unlike vanilla it defines __fastfail.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ICE was fixed (bug #758914), if still run into this then updating
gcc to a newer _p* snapshot should sort it (alternatively, use
released >=gcc-13.1.0).
Note that -fstack-protector* (bug #870136) is still needed, while
mingw64-runtime-11.0.0 add some degree of support, it still seems
to fail for Wine itself.
Bug: https://bugs.gentoo.org/758914
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
| |
Noticed it's only used with gnutls, not worth revbumps.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
| |
Tests for a compiler builtin that is not declared by anything, however
we can lazily ignore it because __clear_cache is not used by wine on
amd64+x86 either way.
Closes: https://bugs.gentoo.org/900332
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
| |
Test is failing on error when it should.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
Ionen Wolkens
Michał Górny
Sam James
Arthur Zamarin
GitWeb