| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Sam James <sam@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>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
|
|
|
|
| |
Signed-off-by: Bernard Cafarelli <voyageur@gentoo.org>
|
|
|
|
| |
Signed-off-by: Bernard Cafarelli <voyageur@gentoo.org>
|
|
|
|
| |
Signed-off-by: Bernard Cafarelli <voyageur@gentoo.org>
|
|
|
|
| |
Signed-off-by: Bernard Cafarelli <voyageur@gentoo.org>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/912373
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
|
|
|
|
| |
Signed-off-by: Viorel Munteanu <ceamac@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/912168
Signed-off-by: Viorel Munteanu <ceamac@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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upon further consideration 9bef96cec566f1e06f5e9c40e52785b7b9702afa
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>
|
|
|
|
|
|
| |
Albeit likely won't visit this until wine-proton-9 and wow64.
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: Michael Mair-Keimberger <mmk@levelnine.at>
Closes: https://github.com/gentoo/gentoo/pull/32295
Signed-off-by: Maciej Barć <xgqt@gentoo.org>
|
|
|
|
| |
Signed-off-by: Joonas Niilola <juippis@gentoo.org>
|
|
|
|
| |
Signed-off-by: Joonas Niilola <juippis@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|