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>
While fixing the bug can allow it to work, there are other
reasons to keep this forced (see wine commits for details).
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>
Michał Górny
Jakov Smolić
Erik Mackdanz
Arthur Zamarin
Mike Lothian
Ferenc Erki
Ionen Wolkens
Ben Kohler
Alfredo Tupone
Anthony G. Basile
Viorel Munteanu
Andreas Sturmlechner