| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Supposedly 9.4 fails to build but builds fine here? And does not
seem like the related bit were disabled. Looking at the bug and
how it was using gcc10 suppose it may only happen with older
toolchains.
Either way 9.4.1 is the hotfix for that.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Normally pkgcheck wouldn't nag about this if it was inside
the 9999 block, but this is a special case where the value
is the same for both.
Meant to keep S closer to SRC_URI still, but fairly harmless
to move it below DESCRIPTION to avoid nagging.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
| |
Use wine-vanilla if you still need 8.x.
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 that this means that it works.
Logic was inverted in 8.21+ 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: 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 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 9e9eec942174e0964b399820071937458f19e62e.
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>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/921360
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
File adds a .md extension, and fwiw use a wildcard so that it
can work with bit older commits too. Haven't kept track which
commit wine-staging is currently based on too so this is safer
without looking closer.
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>
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
| |
Fixed with >=dev-util/pkgcheck-0.10.25-r2 and newer tree-sitter-bash.
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 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).
(not needed with USE="wow64 -abi_x86_32" for 32bit)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quotes given that is only if EXTRA_ECONF is used.
Explored the idea to support it (after bug #912237 is fixed),
and while it works for a basic setup, getting the ebuild *right*
for all configurations quickly got messy and not sure want the
increased maintenance.
To outline some thoughts:
1. USE=-mingw with clang is different than with gcc, gcc won't build
PE files (old layout) while clang needs it (--enable-archs). Meaning
would need a flag to mirror USE=mingw like USE=pe-clang to apply
similar logic with flags, stripping, and other verifications.
-> automagic depending on tc-is-clang is *possible*, but then can't
have e.g. wow64? ( || ( pe-clang mingw ) ) and need to have more
heuristics-based logic
2. test-flags-* cannot be used with `-target *-windows` given there
won't be any runtime (wine does early tests differently), albeit
*could* fallback to a safe CROSSFLAGS="-g -O2" or so
3. not sure want to deal with every future issues with clang cross
no top of mingw's and, on that note, clang-17 is currently broken
with USE=-mingw given don't believe can safely strip -mabi=ms as a
workaround if cross actually gets used
4. there are a lot of combinations to potentially handle, aka
gcc+mingw, gcc w/o mingw, clang w/o mingw, clang+mingw, gcc+pe-clang,
and some of these with either bfd or lld, and with or without 32bit...
And this is turning rather messy and Wine is already kind of fragile
and tracking runtime issues is difficult
5. ...ideally would want to reduce this by forcing mingw even with gcc
(like wine-proton) to simplify, not add more -- albeit if add clang PE
support then it should likely be combined with dropping non-PE support
to balance (i.e. could require clang with USE=-mingw)
6. wine with clang is less tested by distros, users, and well, me
(hardly even try USE=-mingw builds+runtime anymore as-is, including
with gcc), and feel it's better not pretend to support it
Not excluding revisiting, albeit would rather not deal with this at
the moment.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To ensure potential situations where the wine binary would
be overwritten by a symlink don't happen.
Current layout worked but future changes or EXTRA_ECONF can
make it rather fragile. Only changing in 8.13/9999 given wow64
is what complexified this further.
For the record:
abi_x86_64 -abi_x86_32 -wow64 = wine64-only
abi_x86_64 -abi_x86_32 wow64 = wine-only
-abi_x86_64 abi_x86_32 -wow64 = wine-only
abi_x86_64 abi_x86_32 -wow64 = wine and wine64
Could argue that having "wine64" is not really useful, but lot of
scripts and users still expect it and other distros like Alpine are
making the symlink with wow64 too.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upon further consideration 20894379a00ea6f482884d4159217ce3b1bc21a2
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>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Goes away if remove the conf+( CROSS...) block, nested syntax
is probably confusing tree-sitter-bash.
Keep a comment so not removed on a whim.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seems fine, no large binaries nor (obvious) issues at runtime.
Please report if there's major issues that would require forcing
bfd again.
Mold still seems broken, no large binaries but been simply getting
a Segmentation Fault when run winecfg.
So do nothing if recognize bfd or lld, but force whichever is
available otherwise.
Leaving alone for older versions as a precaution.
On a side-note, I hope nobody is passing -fuse-ld=lld in CFLAGS
rather than LDFLAGS where it belongs as this would break compile+link
at once mingw64-toolchain PE tests.
Bug: https://bugs.gentoo.org/867097
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 is required with USE=-mingw, but with USE=mingw 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.
Also add an early abort for USE=-mingw while here, this was always
failing due to missing -mabi=ms even with older clang.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Being work-in-progress should sound less ready than just experimental.
Want to avoid users too eagerly giving up multilib and then having
a hard time to go back when run into issues. Ideally should keep
a testing mindset and multilib around so can switch back&forth.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|